From 340199b78ec8b1d9a39181f58d833866dc6db4d4 Mon Sep 17 00:00:00 2001 From: Wiktor Kwapisiewicz Date: Wed, 15 Nov 2023 10:26:27 +0100 Subject: [PATCH 01/68] Add notes about certificate minimization --- book/source/04-certificates.md | 52 ++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 3f652fc..25a9c23 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -316,6 +316,58 @@ This section only contains notes and still needs to be written Minimized versions, merging, effective "append only" semantics, ... +#### Certificate minimization + +Certificate minimization is a practice of presenting partial view of a certificate by filtering out selected 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/). + +##### Implementations + +GnuPG is [stripping 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: + +> - 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` 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. + +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. + +##### 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. + +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: + +```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 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). + +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. + +##### 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. + +##### 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. + ### "Naming" a certificate in user-facing contexts - fingerprints and beyond ```{admonition} TODO From 8d21b15d56a997ad4c1e267ab498c1637dd9c6c1 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 16 Nov 2023 15:46:54 +0100 Subject: [PATCH 02/68] ch4: restructure "advanced" section --- book/source/04-certificates.md | 46 +++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 25a9c23..a223954 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -305,18 +305,29 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h ## Advanced topics +(append-only)= +### Certificates are effectively "append only" data structures + ```{admonition} TODO :class: warning -This section only contains notes and still needs to be written +- write +- find places in the text that should link to this section (this concept has been hinted at in more than one place, i think) ``` (append-only)= -### Certificate management / Evolution of a certificate over time +### Merging -Minimized versions, merging, effective "append only" semantics, ... +- How to merge two copies of the same certificate? +- Canonicalization -#### Certificate minimization +```{admonition} TODO +:class: warning + +write +``` + +### Certificate minimization Certificate minimization is a practice of presenting partial view of a certificate by filtering out selected components. @@ -325,7 +336,7 @@ Stripping some components has several benefits: - 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/). -##### Implementations +#### Implementations GnuPG is [stripping signatures on key import](https://dev.gnupg.org/T4607#127792). @@ -340,7 +351,7 @@ Besides that GnuPG also offers two ways of cert minimization, described [in thei 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. -##### Autocrypt/WKD minimization +#### 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. @@ -354,7 +365,7 @@ At the time of writing this exported key has exactly 3771 bytes which is signifi 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. -##### Pitfalls of minimization +#### Pitfalls of minimization Disadvantages of minimized certificates: - does not present full view on how the certificate evolved, @@ -363,7 +374,7 @@ Disadvantages of minimized certificates: - 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. -##### Guidelines +#### 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. @@ -378,19 +389,18 @@ In v4, a 20 byte fingerprint in hex representation was used to name certificates For v6, this type of approach is discouraged, but a replacement mechanism is still pending. ``` -### Merging - -- How to merge two copies of the same certificate? -- Canonicalization - -### How to generate "minimized" certificate? - ### When are certificates valid? - Full certificate: Primary revoked/key expired/binding signature expired, - Subkey: Revoked/key expired/binding signature expired - User ID: revoked, binding expired, ... +```{admonition} TODO +:class: warning + +write, link to chapter 9 +``` + ### Best practices regarding Key Freshness ```{admonition} TODO @@ -412,6 +422,12 @@ write ### Metadata leak of Social Graph +```{admonition} TODO +:class: warning + +write +``` + (unbound_user_ids)= ### Adding unbound User IDs to a certificate From 1b3a595815d67284aa965b62322e428746d39bb8 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 16 Nov 2023 19:26:48 +0100 Subject: [PATCH 03/68] add "deflist" to myst_enable_extensions (to render GnuPG documentation excerpt in chapter 4) --- book/source/conf.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/book/source/conf.py b/book/source/conf.py index 2f9972d..9c10089 100644 --- a/book/source/conf.py +++ b/book/source/conf.py @@ -36,6 +36,12 @@ numfig_secnum_depth = 0 # https://github.com/executablebooks/MyST-Parser/issues/352 myst_footnote_transition = False +# Enable definition lists +# https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#syntax-definition-lists +myst_enable_extensions = [ + "deflist", +] + # -- Options for EPUB output ------------------------------------------------- # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-epub-output From b049915e500911a497f78f426b951118b1b7bd2b Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 16 Nov 2023 17:27:04 +0100 Subject: [PATCH 04/68] 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 From 4273dcbd786d0a8d010e3b999154e1cfb4d2eeb3 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 17 Nov 2023 16:03:47 +0100 Subject: [PATCH 05/68] minimization: enumerate things that can be filtered, add section about koo --- book/source/04-certificates.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index e5eab68..028a37b 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -327,6 +327,7 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h write ``` +(cert-mini)= ### Certificate minimization Certificate minimization is the practice of presenting a partial view of a certificate by filtering out some of its components. @@ -337,7 +338,25 @@ Filtering out some elements of a certificate can have different benefits: - 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 +#### Elements that can be omitted as part of a minimization process + +There are different types of elements that can be omitted during minimization: + +- Subkeys (along with signatures on those subkeys) +- Identity components (along with both their self-signatures and third-party signatures) +- Signatures, by themselves: + - Self-signatures that have been superseded by newer self-signatures for the same purpose + - Third-party certifications + +#### Minimization in applications + +##### Hagrid, which runs keys.openpgp.org + +The [hagrid keyserver software](https://gitlab.com/keys.openpgp.org/hagrid) doesn't publish the identity components in certificates by default. This is a central aspect of the [privacy policy](https://keys.openpgp.org/about/privacy) of the service. Certificates can be uploaded to the service by third parties, which is useful. However, identifying information is only distributed by the service on an explicit opt-in basis. + +Separately, third-party certifications are currently filtered out by the service, to avoid flooding attacks. + +##### GnuPG GnuPG [strips some signatures on key import](https://dev.gnupg.org/T4607#127792). From 1e6eaf5d3b4970f2730f65203df52a0e21089b0d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 17 Nov 2023 19:27:52 +0100 Subject: [PATCH 06/68] minimization: add link to autocrypt minimal certificate format --- book/source/04-certificates.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 028a37b..d55bfb0 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -376,6 +376,10 @@ Some implementations, such as Sequoia, prefer to rely on the full historical set 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 + +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 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. From 83d14fa5de9cc8b21691d76a382a51e3b6032987 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 17 Nov 2023 18:03:10 +0100 Subject: [PATCH 07/68] initial draft of "append only" section --- book/source/04-certificates.md | 37 ++++++++++++++++++++++++++++------ 1 file changed, 31 insertions(+), 6 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index d55bfb0..78acf4e 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -306,14 +306,39 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h ## Advanced topics (append-only)= -### Certificates are effectively "append only" data structures +### Certificates are effectively append-only data structures -```{admonition} TODO -:class: warning +OpenPGP certificates act as *append-only data structures*, in practice. By this, we mean that packets that are associated with a certificate cannot be "recalled", once they were published. Third parties (such as other users, or keyservers) may keep and/or distribute copies of those packets. -- write -- find places in the text that should link to this section (this concept has been hinted at in more than one place, i think) -``` +While it is not possible to "remove" elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate. + +Invalidation resembles removal of a component in a semantical sense. The component is not a valid element of the certificate anymore, at least starting from some point in time. Implementations that handle the certificate may omit the invalid component in their representation. + +We have to distinguish the "packet level" information about a certificate from an application-level view of that certificate. The two may differ. + +#### Reasoning about append-only properties in a distributed system + +OpenPGP is a thoroughly distributed system. Users can and do obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, WKD and [autocrypt](https://en.wikipedia.org/wiki/Autocrypt). + +User's OpenPGP software may obtain different views of a particular certificate, over time. These systems have to reconcile and store a combined version of the possibly disparate elements they may obtain from different sources. + +In practice, this means that various OpenPGP users may have differing views of any given certificate. For various reasons, not all users will be in possession of a fully up-to date and complete version of a certificate. + +There are various potential problems associated with this fact: Users may not be aware that a component has been invalidated by the certificate holder. Revocations may not have been propagated to some third party. So for example, they may not be aware that the certificate holder has rotated their encryption subkey to a new one, and doesn't want to receive messages encrypted to the previous encryption subkey. + +A defensive approach to this fact of distributed system is to "assume the worst". There are different ways of thinking about this: + +- Recipients may not obtain updates to a certificate in a timely manner (this could happen for various reasons, including, but not limited to, interference by malicious actors). +- Data that is associated with a certificate may compound, and can become too large for convenient handling. If such a problem arises, then by definition, the certificate holder cannot address it: recall that the certificate holder cannot "recall" existing packets. + +#### Differing "views" of a certificate exist + +Another way to think about this discussion is that different OpenPGP users may have a different view of any certificate. There is a notional "canonical" version of the certificate, but we cannot assume that every user has exactly this copy. Besides propagation of elements that the certificate holder has linked to a certificate, third-party certifications are by design a distributed mechanism. A third-party certification is issued by a third party, and may or may not be distributed widely by them, or by the certificate holder. Not distributing third-party certifications widely is a workflow that may be entirely appropriate for some use cases. + +As a general tendency, it is desirable for OpenPGP users to have the most complete possible view of all certificates that they interact with. + +However, there are contexts in which implementations may prefer to handle only a subset of the elements of a certificate. We discuss this in the section +{ref}`cert-mini`. (append-only)= ### Merging From 3a2d8cad552f573ec2717e3c8367183990c8b2ee Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 17 Nov 2023 19:28:40 +0100 Subject: [PATCH 08/68] initial draft of "merging" section --- book/source/04-certificates.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 78acf4e..d329f30 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -343,15 +343,15 @@ However, there are contexts in which implementations may prefer to handle only a (append-only)= ### Merging +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. + +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 -```{admonition} TODO -:class: warning - -write -``` - (cert-mini)= ### Certificate minimization From 060419b34eed1bd7e6e5224d05eae2159f80ec80 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 17 Nov 2023 20:14:51 +0100 Subject: [PATCH 09/68] initial draft of "naming/fingerprints" section --- book/source/04-certificates.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index d329f30..0ce7df8 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -437,15 +437,25 @@ Disadvantages/risks of minimizing certificates: 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. -### "Naming" a certificate in user-facing contexts - fingerprints and beyond +### Fingerprints and beyond: "Naming" certificates in user-facing contexts -```{admonition} TODO -:class: warning +#### Version 4 -In v4, a 20 byte fingerprint in hex representation was used to name certificates, even in user-facing contexts. +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. -For v6, this type of approach is discouraged, but a replacement mechanism is still pending. -``` +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. + +#### Version 6 + +The OpenPGP version 6 standard uses 32 byte fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows. + +Instead, "mechanical fingerprint transfer and comparison" should be preferred, wherever possible. The reasoning is that humans tend to be bad at comparing high-entropy data (in addition, many users are probably put off by being asked to compare long hexadecimal strings). + +#### Use in APIs + +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. ### When are certificates valid? From 0a69d68a731e07bde3a3cd15676ddca8b0833226 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 18 Nov 2023 17:45:52 +0100 Subject: [PATCH 10/68] move dks vs. primary uid note to advanced section --- book/source/04-certificates.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0ce7df8..41c7a83 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -480,12 +480,16 @@ write, link to chapter 9 Wiktor suggests to check: https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/ for important material ``` +(dks-puid)= ### Metadata about the primary key: In Direct Key Signature vs. in Primary User ID, in v4 and v6 ```{admonition} TODO :class: warning -write +i think crypto-refresh suggests that the direct key signature should hold the default preferences? +we might need to write a more nuanced text here, about how DKS and primary user id interact in v6, and mention the differences to v4? + +the primary User ID can also specify metadata about the primary key ``` ### Metadata leak of Social Graph From 13d99545021cc092ddc9e35b27d8b4933328b0f1 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 15:21:12 +0100 Subject: [PATCH 11/68] removing "Metadata about the primary key: In Direct Key Signature vs. in Primary User ID, in v4 and v6" from ch4. this content should go into ch8. --- book/source/04-certificates.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 41c7a83..0b1e197 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -480,18 +480,6 @@ write, link to chapter 9 Wiktor suggests to check: https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/ for important material ``` -(dks-puid)= -### Metadata about the primary key: In Direct Key Signature vs. in Primary User ID, in v4 and v6 - -```{admonition} TODO -:class: warning - -i think crypto-refresh suggests that the direct key signature should hold the default preferences? -we might need to write a more nuanced text here, about how DKS and primary user id interact in v6, and mention the differences to v4? - -the primary User ID can also specify metadata about the primary key -``` - ### Metadata leak of Social Graph ```{admonition} TODO From 61ada929e7c33b931bf25b1ff1dc53cb9a3dca4e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 17:50:36 +0100 Subject: [PATCH 12/68] ch4: process feedback from wiktor --- book/source/04-certificates.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0b1e197..73651a1 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -310,7 +310,7 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h OpenPGP certificates act as *append-only data structures*, in practice. By this, we mean that packets that are associated with a certificate cannot be "recalled", once they were published. Third parties (such as other users, or keyservers) may keep and/or distribute copies of those packets. -While it is not possible to "remove" elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate. +While it is not possible to "remove" elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate. Invalidation resembles removal of a component in a semantical sense. The component is not a valid element of the certificate anymore, at least starting from some point in time. Implementations that handle the certificate may omit the invalid component in their representation. @@ -318,7 +318,7 @@ We have to distinguish the "packet level" information about a certificate from a #### Reasoning about append-only properties in a distributed system -OpenPGP is a thoroughly distributed system. Users can and do obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, WKD and [autocrypt](https://en.wikipedia.org/wiki/Autocrypt). +OpenPGP is a thoroughly distributed system. Users can obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, WKD and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). User's OpenPGP software may obtain different views of a particular certificate, over time. These systems have to reconcile and store a combined version of the possibly disparate elements they may obtain from different sources. @@ -326,10 +326,18 @@ In practice, this means that various OpenPGP users may have differing views of a There are various potential problems associated with this fact: Users may not be aware that a component has been invalidated by the certificate holder. Revocations may not have been propagated to some third party. So for example, they may not be aware that the certificate holder has rotated their encryption subkey to a new one, and doesn't want to receive messages encrypted to the previous encryption subkey. -A defensive approach to this fact of distributed system is to "assume the worst". There are different ways of thinking about this: +One mechanism that addresses a part of this issue is *expiration*: By setting their certificates to expire after an appropriate interval, certificate holders can force their communication partners to refresh their certificate, e.g. from a keyserver[^mgorny]. + +[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration dates really serve two purposes: naturally eliminating unused keys, and enforcing periodical checks on the primary key." + +Good practices, like setting appropriate expiration times, can mitigate the complexity of the inherently distributed nature of certificates. + +However, such mitigations by definition cannot address all possible cases of outdated certificate information in a decentralized, asynchronous system such as OpenPGP. So a defensive approach is generally appropriate when reasoning about the view of certificates that different actors have. + +When thinking about edge cases, it's useful to "assume the worst." For example: - Recipients may not obtain updates to a certificate in a timely manner (this could happen for various reasons, including, but not limited to, interference by malicious actors). -- Data that is associated with a certificate may compound, and can become too large for convenient handling. If such a problem arises, then by definition, the certificate holder cannot address it: recall that the certificate holder cannot "recall" existing packets. +- Data associated with a certificate may compound, and can become too large for convenient handling. If such a problem arises, then by definition, the certificate holder cannot address it: recall that the certificate holder cannot "recall" existing packets. #### Differing "views" of a certificate exist From 113077109bc8a2db95967648b2fd1dff58493628 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 18:45:30 +0100 Subject: [PATCH 13/68] ch4: merging: process feedback from paul in #121 --- book/source/04-certificates.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 73651a1..036dfd1 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -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 From 0cbc590c19057e36d205ed76ed3f4581bd8e89fa Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 19:05:44 +0100 Subject: [PATCH 14/68] Attempt at generalization, based on wiktor's input --- book/source/04-certificates.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 036dfd1..a50fa62 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -345,8 +345,7 @@ Another way to think about this discussion is that different OpenPGP users may h As a general tendency, it is desirable for OpenPGP users to have the most complete possible view of all certificates that they interact with. -However, there are contexts in which implementations may prefer to handle only a subset of the elements of a certificate. We discuss this in the section -{ref}`cert-mini`. +However, there are contexts in which it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`cert-mini`. (append-only)= ### Merging From f3da8a4dcda15d60ae17cb9b90cbd67312837962 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 19:16:06 +0100 Subject: [PATCH 15/68] 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? From 2b4ab56165608407c1f55a9bb4b847d44483e658 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 20:45:41 +0100 Subject: [PATCH 16/68] Minor edit --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 27be16a..d800c8a 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -437,7 +437,7 @@ Note that in some contexts it's not clear if minimization brings more benefit th Disadvantages/risks of minimizing certificates: -- Does not present full view of how the certificate (and the validity of its components) evolved over time. +- Does not present a 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). From c05d0394f2ae6ab39dbd04583db2bb81560d1d85 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 19:21:55 +0100 Subject: [PATCH 17/68] Clarification from Paul via #121 --- book/source/04-certificates.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index d800c8a..9961d32 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -410,7 +410,9 @@ In addition, GnuPG offers two explicit methods for certificate minimization, des 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. +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 binding self-signatures that predate the current self-signature of the primary key[^primary-self-sig]. + +[^primary-self-sig]: Which in OpenPGP version 4 is often a primary User ID binding signature. #### Autocrypt From f428ed956fffbe238314402fae5751088d65c0f2 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 19:51:33 +0100 Subject: [PATCH 18/68] Clarification from Wiktor via #121 --- book/source/04-certificates.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 9961d32..c199353 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -410,7 +410,11 @@ In addition, GnuPG offers two explicit methods for certificate minimization, des 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 binding self-signatures that predate the current self-signature of the primary key[^primary-self-sig]. +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. See [this discussion](https://github.com/rpm-software-management/rpm-sequoia/issues/50#issuecomment-1689642607) for details: + +Initially, when checking the validity of a data signature for a software package, `rpm-sequoia` used the signature's creation time as the reference time. However, the availability of historical self-signatures in certificates is limited. So sometimes only a more recent self-signature for the primary key is available, and there is no evidence that the primary key was valid at the reference time. + +To deal with this reality, the rpm-sequoia implementation was adjusted to accept data signatures that predate the validity of the current primary key self-signature[^primary-self-sig]. [^primary-self-sig]: Which in OpenPGP version 4 is often a primary User ID binding signature. From daaf172ccaf8ffb241f4d838797fbcf9bced8f10 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 20:37:41 +0100 Subject: [PATCH 19/68] Attempt at clarification, triggered by Paul's feedback in #121 --- book/source/04-certificates.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index c199353..5309438 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -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 From 04be4cd927cbf428fd38d34afb2230a73bf2e1bc Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 22:31:27 +0100 Subject: [PATCH 20/68] ch4: add text for "Certificate freshness" --- book/source/04-certificates.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 5309438..0b4e78f 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -496,16 +496,16 @@ The historical 4-byte "short Key IDs" format should not be used anywhere, anymor write, link to chapter 9 ``` -### Best practices regarding Key Freshness +(cert-freshness)= +### Certificate freshness: Triggering updates with expiration -```{admonition} TODO -:class: warning +For a certificate holder, one problem is that communication partners may not regularly poll for updates of their certificate. -- Expiry -- Subkey rotation +A certificate holder usually prefers that everyone else regularly obtains updates for their certificate. This way, a third party will, for example, not mistakenly keep using the certificate indefinitely, in case it gets revoked. Instead, in the worst case, someone will use the certificate until the expiration date. -Wiktor suggests to check: https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/ for important material -``` +Once the expiration date is reached, third parties, or ideally their OpenPGP software will have to obtain an update for the certificate. For example, from a keyserver, or via WKD. Ideally, certificate updates are obtained automatically, by the user's OpenPGP software, without any need for human intervention. + +After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached. ### Metadata leak of Social Graph From 6a14882687e3d9f95876307a9d2418403b177744 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 22 Nov 2023 22:31:57 +0100 Subject: [PATCH 21/68] ch4: move certificate validity up --- book/source/04-certificates.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0b4e78f..f64ca9c 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -305,6 +305,18 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h ## Advanced topics +### When are certificates valid? + +- Full certificate: Primary revoked/key expired/binding signature expired, +- Subkey: Revoked/key expired/binding signature expired +- User ID: revoked, binding expired, ... + +```{admonition} TODO +:class: warning + +write, link to chapter 9 +``` + (append-only)= ### Certificates are effectively append-only data structures @@ -484,18 +496,6 @@ Note that regardless of the OpenPGP version, software that relies on 8-byte Key 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? - -- Full certificate: Primary revoked/key expired/binding signature expired, -- Subkey: Revoked/key expired/binding signature expired -- User ID: revoked, binding expired, ... - -```{admonition} TODO -:class: warning - -write, link to chapter 9 -``` - (cert-freshness)= ### Certificate freshness: Triggering updates with expiration From a5f3ea98e84e5b6f40cef0948169dd85d9582e86 Mon Sep 17 00:00:00 2001 From: Wiktor Kwapisiewicz Date: Fri, 24 Nov 2023 11:22:23 +0100 Subject: [PATCH 22/68] Add 'When are certificates valid' --- book/source/04-certificates.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index f64ca9c..349b059 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -307,15 +307,13 @@ The popular [SKS keyserver network experienced certificate flooding firsthand](h ### When are certificates valid? -- Full certificate: Primary revoked/key expired/binding signature expired, -- Subkey: Revoked/key expired/binding signature expired -- User ID: revoked, binding expired, ... +Certificates are composed out of smaller parts and connected back to the primary key with [signatures](08-signing_components). Since OpenPGP certificates are *append only* data structure, previous signatures can be revoked by issuing revocation signatures and appending them to the certificate. This also means that each component such as User ID and a subkey may be revoked without affecting the rest of the certificate. A special case is a Key revocation signature (type ID 0x20) which marks the primary key as revoked and that indirectly makes all other components unusable. -```{admonition} TODO -:class: warning +A related concept is [key expiration](#cert-freshness), that also makes the component unusable, but compared to revocations, which are final, expiration is just a reminder for certificate users that the certificate is not fresh and a newer version should be aquired. Only primary keys are using Key Expiration Time subpackets for expressing the expiration time. All other components rely on the expiration of their binding signature. If the binding signature expires, the binding becomes invalid, and the component is considered expired. -write, link to chapter 9 -``` +Revocation, on the other hand, is final and cannot be withdrawn and indicates that the component should not be used. Revocation signatures over components use Reason for Revocation subpacket to specify further details about the reason why the component or certification was revoked. + +Some libraries such as Sequoia PGP follow the guidance of the RFC and differentiate revocation signatures based on the Reason for Revocation subpacket. `Key is superseded`, `Key is retired` and `User ID is no longer valid` are considered "soft" revocations. Any other reason makes the revocation "hard". The distinction plays a role when Sequoia constructs a view of the certificate at a specified point in time. Selecting the time before a soft revocation has been made makes the component valid but if the revocation is hard then it's considered invalid at any point in time. The distinction stems from the following attack: if the key was compromised then the attacker can issue backdated signatures, so it's important to always consider compromised keys as suspect. On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey then the signatures in the past, made by the retired key, are still correct. (append-only)= ### Certificates are effectively append-only data structures From 1684b3556730e538cc3b79344a39d40dddffd3ae Mon Sep 17 00:00:00 2001 From: Wiktor Kwapisiewicz Date: Fri, 24 Nov 2023 12:46:03 +0100 Subject: [PATCH 23/68] Add a brief explanation of the metadata leak --- book/source/04-certificates.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 349b059..9d681b8 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -507,11 +507,11 @@ After the update, the updated copy of the certificate will usually have a fresh ### Metadata leak of Social Graph -```{admonition} TODO -:class: warning +Third-party certifications, which are signatures made by other certificates, over identity components, form a back-bone of OpenPGP trust-model called the Web of Trust. The name stems from the fact that the collection of certifications forms a unidirectional graph resembling a web. Each edge of graph connects the signing certificate to the identity component associated with another certificate. -write -``` +OpenPGP software can inspect that graph, and coupled with trust data and a trust anchor (which usually is the certificate holder's own key), can infer whether the target certificate is genuine. + +Third-party certifications are published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, as a side-effect of this approach it's feasible to reconstruct the entire social graph of all people issuing certifications. The certification's signature creation time can be used to deduct whether the ceritifate owner attended a Key Signing Party (and if it was public where was it) and whom they interacted with. (unbound_user_ids)= ### Adding unbound User IDs to a certificate From 87c2a655675b4f420839190f39bd9a7fb366460c Mon Sep 17 00:00:00 2001 From: Wiktor Kwapisiewicz Date: Fri, 24 Nov 2023 13:20:55 +0100 Subject: [PATCH 24/68] Add more explanation to unbound User IDs --- book/source/04-certificates.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 9d681b8..868679e 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -516,13 +516,11 @@ Third-party certifications are published as part of the target certificate to fa (unbound_user_ids)= ### Adding unbound User IDs to a certificate -```{admonition} TODO -:class: warning +Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). -references/links missing -``` +[PET]: https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model -Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches "pet-names" to certificates, in this way). +Sequoia additionally certifies these foreign User IDs with the local trust root to facilitate authentication of certificates but marks all this additional signatures with a Non Exportable subpacket so that they are not visible when publishing the certificate e.g. on keyservers. ### Third-party certification flooding From cfe2b34669b1c80f6e3908e810a8a4a30ea88183 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 14:03:10 +0100 Subject: [PATCH 25/68] todo: merge in flooding text from ch8 --- book/source/04-certificates.md | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 868679e..5cd7c62 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -292,17 +292,6 @@ This process assumes that Bob knows the person known as `Alice Adams` and is con For more on third-party {term}`certifications`, see {ref}`third_party_cert`. -(cert-flooding)= -### Security considerations - -While a convenience for consumers, indiscriminately accepting and integrating {term}`third-party identity certifications` comes with significant risks. - -Without any restrictions in place, malicious entities can flood a {term}`certificate` with excessive {term}`certifications`. Called "certificate flooding," this form of digital vandalism grossly expands the {term}`certificate` size, making the {term}`certificate` cumbersome and impractical for users. - -It also opens the door to potential denial-of-service attacks, rendering the {term}`certificate` non-functional or significantly impeding its operation. - -The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019. - ## Advanced topics ### When are certificates valid? @@ -522,6 +511,7 @@ Some OpenPGP subsystems may add User IDs to a certificate, which are not bound t Sequoia additionally certifies these foreign User IDs with the local trust root to facilitate authentication of certificates but marks all this additional signatures with a Non Exportable subpacket so that they are not visible when publishing the certificate e.g. on keyservers. +(cert-flooding)= ### Third-party certification flooding While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks. @@ -530,4 +520,10 @@ Without any restrictions in place, malicious entities can flood a certificate wi It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation. -The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019. +The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019. + +TODO: merge in text from ch8: + +```text +However, in systems that unconditionally accept these certifications, it can lead to unintended consequences. Specifically, this approach has been exploited to cause denial-of-service attacks through [certificate flooding](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), a problem notably experienced by the SKS network of OpenPGP servers. +``` From 59d956c706d98c1c28b6a742888c32852964a2fa Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 20:23:53 +0100 Subject: [PATCH 26/68] minor fixes --- book/source/04-certificates.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 5cd7c62..c075e5c 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -298,11 +298,11 @@ For more on third-party {term}`certifications`, see {ref}`third_p Certificates are composed out of smaller parts and connected back to the primary key with [signatures](08-signing_components). Since OpenPGP certificates are *append only* data structure, previous signatures can be revoked by issuing revocation signatures and appending them to the certificate. This also means that each component such as User ID and a subkey may be revoked without affecting the rest of the certificate. A special case is a Key revocation signature (type ID 0x20) which marks the primary key as revoked and that indirectly makes all other components unusable. -A related concept is [key expiration](#cert-freshness), that also makes the component unusable, but compared to revocations, which are final, expiration is just a reminder for certificate users that the certificate is not fresh and a newer version should be aquired. Only primary keys are using Key Expiration Time subpackets for expressing the expiration time. All other components rely on the expiration of their binding signature. If the binding signature expires, the binding becomes invalid, and the component is considered expired. +A related concept is [key expiration](#cert-freshness), that also makes the component unusable, but compared to revocations, which are final, expiration is just a reminder for certificate users that the certificate is not fresh and a newer version should be acquired. Only primary keys are using Key Expiration Time subpackets for expressing the expiration time. All other components rely on the expiration of their binding signature. If the binding signature expires, the binding becomes invalid, and the component is considered expired. Revocation, on the other hand, is final and cannot be withdrawn and indicates that the component should not be used. Revocation signatures over components use Reason for Revocation subpacket to specify further details about the reason why the component or certification was revoked. -Some libraries such as Sequoia PGP follow the guidance of the RFC and differentiate revocation signatures based on the Reason for Revocation subpacket. `Key is superseded`, `Key is retired` and `User ID is no longer valid` are considered "soft" revocations. Any other reason makes the revocation "hard". The distinction plays a role when Sequoia constructs a view of the certificate at a specified point in time. Selecting the time before a soft revocation has been made makes the component valid but if the revocation is hard then it's considered invalid at any point in time. The distinction stems from the following attack: if the key was compromised then the attacker can issue backdated signatures, so it's important to always consider compromised keys as suspect. On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey then the signatures in the past, made by the retired key, are still correct. +Some libraries such as Sequoia PGP follow the guidance of the RFC and differentiate revocation signatures based on the Reason for Revocation subpacket. `Key is superseded`, `Key is retired` and `User ID is no longer valid` are considered "soft" revocations. Any other reason makes the revocation "hard." The distinction plays a role when Sequoia constructs a view of the certificate at a specified point in time. Selecting the time before a soft revocation has been made makes the component valid, but if the revocation is hard then it's considered invalid at any point in time. The distinction stems from the following attack: if the key was compromised, then the attacker can issue backdated signatures, so it's important to always consider compromised keys as suspect. On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. (append-only)= ### Certificates are effectively append-only data structures @@ -346,7 +346,6 @@ As a general tendency, it is desirable for OpenPGP users to have the most comple However, there are contexts in which it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`cert-mini`. -(append-only)= ### Merging 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. From 5c73827f28c30b762556bd128219b8eba106293e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 27 Nov 2023 00:16:36 +0100 Subject: [PATCH 27/68] typo fix --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index c075e5c..116b373 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -370,7 +370,7 @@ 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/). +- Sometimes, a certificate organically grows so big that the user software [has problems handling it](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/). #### Elements that can be omitted as part of a minimization process From 479419988448e3b4f67598d0020bfa6c44c5222d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 26 Nov 2023 23:23:49 +0100 Subject: [PATCH 28/68] ch4: edits to "Certificate validity" section --- book/source/04-certificates.md | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 116b373..371d1f6 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -296,13 +296,29 @@ For more on third-party {term}`certifications`, see {ref}`third_p ### When are certificates valid? -Certificates are composed out of smaller parts and connected back to the primary key with [signatures](08-signing_components). Since OpenPGP certificates are *append only* data structure, previous signatures can be revoked by issuing revocation signatures and appending them to the certificate. This also means that each component such as User ID and a subkey may be revoked without affecting the rest of the certificate. A special case is a Key revocation signature (type ID 0x20) which marks the primary key as revoked and that indirectly makes all other components unusable. +Certificates are composites of components that are linked together using [signatures](08-signing_components). Here we discuss how to determine if a certificate in its entirety, or one of its components, individually, is valid. -A related concept is [key expiration](#cert-freshness), that also makes the component unusable, but compared to revocations, which are final, expiration is just a reminder for certificate users that the certificate is not fresh and a newer version should be acquired. Only primary keys are using Key Expiration Time subpackets for expressing the expiration time. All other components rely on the expiration of their binding signature. If the binding signature expires, the binding becomes invalid, and the component is considered expired. +Certificate validity - discussed here - is related to [signature validity](verification_chapter), and builds on that concept. + +#### Revocation + +Since OpenPGP certificates are effectively an [*append only*](append-only) data structure, existing signatures are revoked by issuing revocation signatures, and adding them to the certificate. + +Each component, such as User ID and a subkey, may be revoked without affecting the rest of the certificate. A special case is a Key revocation signature (type ID `0x20`), which marks the primary key as revoked and indirectly makes all other components unusable. + +#### Expiration + +A related concept is [key expiration](#cert-freshness), which also makes the component unusable. However, compared to revocations, which are final, expiration is just a reminder for certificate users that the certificate is not fresh and a newer version should be acquired. Only primary keys are using Key Expiration Time subpackets for expressing the expiration time. All other components rely on the expiration of their binding signature. If the binding signature expires, the binding becomes invalid, and the component is considered expired. + +#### Semantics of Revocation Revocation, on the other hand, is final and cannot be withdrawn and indicates that the component should not be used. Revocation signatures over components use Reason for Revocation subpacket to specify further details about the reason why the component or certification was revoked. -Some libraries such as Sequoia PGP follow the guidance of the RFC and differentiate revocation signatures based on the Reason for Revocation subpacket. `Key is superseded`, `Key is retired` and `User ID is no longer valid` are considered "soft" revocations. Any other reason makes the revocation "hard." The distinction plays a role when Sequoia constructs a view of the certificate at a specified point in time. Selecting the time before a soft revocation has been made makes the component valid, but if the revocation is hard then it's considered invalid at any point in time. The distinction stems from the following attack: if the key was compromised, then the attacker can issue backdated signatures, so it's important to always consider compromised keys as suspect. On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. +Some libraries such as Sequoia PGP follow the guidance of the RFC and differentiate revocation signatures based on the Reason for Revocation subpacket. `Key is superseded`, `Key is retired` and `User ID is no longer valid` are considered "soft" revocations. Any other reason makes the revocation "hard." + +The distinction plays a role when Sequoia constructs a view of the certificate at a specified point in time. Selecting the time before a soft revocation has been made shows the component as valid. But for a hard revocation, it is considered invalid at any point in time. + +The distinction addresses the following attack: If a key was compromised, then the attacker can issue backdated signatures, so it's important to always consider compromised keys as suspect. On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. (append-only)= ### Certificates are effectively append-only data structures From 029b774f25d6fc443db4710e5431f6491b64abf0 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 15:11:18 +0100 Subject: [PATCH 29/68] ch4: certificate validity --- book/source/04-certificates.md | 51 ++++++++++++++++++++++++++-------- 1 file changed, 40 insertions(+), 11 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 371d1f6..2054ce2 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -296,29 +296,58 @@ For more on third-party {term}`certifications`, see {ref}`third_p ### When are certificates valid? -Certificates are composites of components that are linked together using [signatures](08-signing_components). Here we discuss how to determine if a certificate in its entirety, or one of its components, individually, is valid. +Certificates are composites of components that are linked together using [signatures](08-signing_components). -Certificate validity - discussed here - is related to [signature validity](verification_chapter), and builds on that concept. +A certificate can be valid or invalid as a whole. However, even when a certificate is valid, individual components (subkeys or identities) of it can be invalid. -#### Revocation +In this section, we discuss the validity of certificates and their components. This discussion is closely related to [signature validity](verification_chapter), and builds on that concept. -Since OpenPGP certificates are effectively an [*append only*](append-only) data structure, existing signatures are revoked by issuing revocation signatures, and adding them to the certificate. +The validity of the signatures that link a certificate is a necessary precondition. Two concepts are particularly central to the validity of certificates and components: -Each component, such as User ID and a subkey, may be revoked without affecting the rest of the certificate. A special case is a Key revocation signature (type ID `0x20`), which marks the primary key as revoked and indirectly makes all other components unusable. +- Expiration +- Revocation #### Expiration -A related concept is [key expiration](#cert-freshness), which also makes the component unusable. However, compared to revocations, which are final, expiration is just a reminder for certificate users that the certificate is not fresh and a newer version should be acquired. Only primary keys are using Key Expiration Time subpackets for expressing the expiration time. All other components rely on the expiration of their binding signature. If the binding signature expires, the binding becomes invalid, and the component is considered expired. +Certificates and components can "expire," which renders them invalid. Each component of a certificate can have an expiration time, or be unlimited in its temporal validity. -#### Semantics of Revocation +The OpenPGP software of a sender will refuse to encrypt email to an expired certificate, or to an encryption component key that is expired. The sender's software rejects encryption to the key, essentially as a courtesy to the certificate owner, respecting the preferences expressed in their certificate metadata. -Revocation, on the other hand, is final and cannot be withdrawn and indicates that the component should not be used. Revocation signatures over components use Reason for Revocation subpacket to specify further details about the reason why the component or certification was revoked. +The expiration mechanism in OpenPGP is complemented by a mechanism to extend/renew expiration time. -Some libraries such as Sequoia PGP follow the guidance of the RFC and differentiate revocation signatures based on the Reason for Revocation subpacket. `Key is superseded`, `Key is retired` and `User ID is no longer valid` are considered "soft" revocations. Any other reason makes the revocation "hard." +Using the expiration mechanism is useful for two reasons: -The distinction plays a role when Sequoia constructs a view of the certificate at a specified point in time. Selecting the time before a soft revocation has been made shows the component as valid. But for a hard revocation, it is considered invalid at any point in time. +- Expiration of a certificate reminds users of that certificate to poll for updates, for example, from a keyserver. that the certificate is not fresh and a newer version should be acquired. +- It is a passive way for certificates to "time out," e.g., if their owner loses control over them, or isn't able to broadcast a revocation, for any reason. -The distinction addresses the following attack: If a key was compromised, then the attacker can issue backdated signatures, so it's important to always consider compromised keys as suspect. On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. +Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the expiration of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired. + +#### Revocation + +Since OpenPGP certificates act as ["append only" data structures](append-only), existing components or signatures cannot simply be "removed." Instead, they can be marked as invalid by issuing revocation signatures. These additional revocation signatures are added to the certificate. + +Each component, such as User ID and a subkey, may be revoked without affecting the rest of the certificate. + +Revoking the primary key with a [*Key revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) (type ID `0x20`) is a special case: This marks the entire certificate, including all of its components unusable. + +#### Semantics of Revocations + +In contrast to expiration, revocation is typically final and not withdrawn. + +A revocation indicates that the component should not be used. Revocation signatures over components use a [*Reason for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation) subpacket to specify further details about the reason why the component or certification was revoked. The OpenPGP format specifies a set of distinct [values for *Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#table-10), and additionally provides space for a human-readable free text field for comments about the revocation. + +Some libraries, such as Sequoia PGP, expose these distinct reasons for users, enabling nuanced machine-readable statements by the revoker. Other implementations focus mainly on the distinction between "hard" and "soft" revocations. + +Of the defined revocation types, *Key is superseded*, *Key is retired* and *User ID is no longer valid* are considered "soft" revocations. Any other reason (including a missing *reason for revocation* subpacket) means that the revocation is "hard." + +The distinction between hard and soft revocations plays a role when evaluating the validity of a component or signature at a specified reference time: Hard revocations have unbounded [temporal validity](temporal-validity), they are in effect even before their creation time. Hard revocations invalidate the revoked component or signature at all points in time. + +By contrast, a soft revocation leaves the revoked component or signature valid before the creation time of the revocation signature. A soft revocation can technically be overridden, for example, with a newer binding signature. + +Hard revocations address the following problem: If a private key was compromised, then the attacker can issue signatures using that key. This means, the attacker could issue a signature dated before the revocation, impersonating the owner of the key. A recipient of that signature would mistakenly consider this signature valid if the issuing key has been soft revoked. This is a problem. +To counteract this problem, it is reasonable to clearly mark compromised keys as suspect at any point in time. That's what hard revocations do. + +On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. (append-only)= ### Certificates are effectively append-only data structures From 5b9070e019d0de582ef55fc95532f978bdf9ccfe Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 16:24:59 +0100 Subject: [PATCH 30/68] ch4: extend "naming" --- book/source/04-certificates.md | 36 ++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 2054ce2..eaf6709 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -507,19 +507,25 @@ Disadvantages/risks of minimizing certificates: ### Fingerprints and beyond: "Naming" certificates in user-facing contexts -#### Version 4 +Certificates in OpenPGP have traditionally often been "named" using hexadecimal strings of varying length. -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, a business card might have shown the hexadecimal fingerprint of a person's OpenPGP certificate to facilitate secure communication. Over time, different formats and lengths for these identifiers have been used. + +This section outlines the various ways in which certificates can be named, and their properties. + +#### Fingerprints and Key IDs in Version 4 + +With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte (160 bit) *fingerprints* as an identifier for the certificate. Or alternatively, the 8 byte (64 bit) *Key ID* variant 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. Users were asked to manually verify that the fingerprint corresponds to the expected certificate. -#### Version 6 +#### Fingerprints in Version 6 -The OpenPGP version 6 standard uses 32 byte fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows. +The OpenPGP version 6 standard uses 32 byte (256 bit) fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows. Instead, "mechanical fingerprint transfer and comparison" should be preferred, wherever possible. The reasoning is that humans tend to be bad at comparing high-entropy data (in addition, many users are probably put off by being asked to compare long hexadecimal strings). -#### Use in APIs +#### Use of Fingerprints and Key IDs in APIs 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. @@ -527,6 +533,24 @@ Note that regardless of the OpenPGP version, software that relies on 8-byte Key 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/)). +#### Looking up certificates by email + +Searching OpenPGP certificates by email is a use case that often arises. For example, when composing an email to a new contact, the sender may want to find the OpenPGP certificate for that contact. + +Different mechanisms allow certificate lookup by email, for example: + +- [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) +- The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs) +- Traditional-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) + +Their properties differ: + +- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. +- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. +- *Traditional keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). + +[^hip1]: + (cert-freshness)= ### Certificate freshness: Triggering updates with expiration @@ -544,7 +568,7 @@ Third-party certifications, which are signatures made by other certificates, ove OpenPGP software can inspect that graph, and coupled with trust data and a trust anchor (which usually is the certificate holder's own key), can infer whether the target certificate is genuine. -Third-party certifications are published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, as a side-effect of this approach it's feasible to reconstruct the entire social graph of all people issuing certifications. The certification's signature creation time can be used to deduct whether the ceritifate owner attended a Key Signing Party (and if it was public where was it) and whom they interacted with. +Third-party certifications are published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, as a side effect of this approach, it's feasible to reconstruct the entire social graph of all people issuing certifications. The certification's signature creation time can be used to deduct whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with. (unbound_user_ids)= ### Adding unbound User IDs to a certificate From c8a228a8797c71d196a9912d50e56ad59b48b45e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 17:51:00 +0100 Subject: [PATCH 31/68] ch4: freshness --- book/source/04-certificates.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index eaf6709..70e7b5b 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -552,13 +552,13 @@ Their properties differ: [^hip1]: (cert-freshness)= -### Certificate freshness: Triggering updates with expiration +### Certificate freshness: Triggering updates with an expiration time -For a certificate holder, one problem is that communication partners may not regularly poll for updates of their certificate. +For a certificate holder, one problem is that their communication partners may not regularly poll for updates of their certificate. -A certificate holder usually prefers that everyone else regularly obtains updates for their certificate. This way, a third party will, for example, not mistakenly keep using the certificate indefinitely, in case it gets revoked. Instead, in the worst case, someone will use the certificate until the expiration date. +A certificate holder usually prefers that everyone else regularly obtains updates for their certificate. This way, a third party will, for example, not mistakenly keep using the certificate indefinitely, after it gets revoked. Setting an expiration time on the certificate, ahead of time, limits the worst case scenario: communication partners will at most use a revoked certificate until its expiration time, even if they never learn of the revocation. -Once the expiration date is reached, third parties, or ideally their OpenPGP software will have to obtain an update for the certificate. For example, from a keyserver, or via WKD. Ideally, certificate updates are obtained automatically, by the user's OpenPGP software, without any need for human intervention. +Once the expiration time is reached, third parties, or ideally their OpenPGP software will have to stop using the certificate, and may attempt to obtain an update for it. For example, from a keyserver, or via WKD. Ideally, certificate updates are obtained automatically, by the user's OpenPGP software, without any need for human intervention. After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached. From 46a0429b4dcb907e27dc68bee18779c4b12e6155 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 18:10:09 +0100 Subject: [PATCH 32/68] ch4: metadata leak --- book/source/04-certificates.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 70e7b5b..7d36807 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -533,6 +533,7 @@ Note that regardless of the OpenPGP version, software that relies on 8-byte Key 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/)). +(email-lookup)= #### Looking up certificates by email Searching OpenPGP certificates by email is a use case that often arises. For example, when composing an email to a new contact, the sender may want to find the OpenPGP certificate for that contact. @@ -564,11 +565,20 @@ After the update, the updated copy of the certificate will usually have a fresh ### Metadata leak of Social Graph -Third-party certifications, which are signatures made by other certificates, over identity components, form a back-bone of OpenPGP trust-model called the Web of Trust. The name stems from the fact that the collection of certifications forms a unidirectional graph resembling a web. Each edge of graph connects the signing certificate to the identity component associated with another certificate. +Third-party certifications are signatures over identity components made by other certificates. -OpenPGP software can inspect that graph, and coupled with trust data and a trust anchor (which usually is the certificate holder's own key), can infer whether the target certificate is genuine. +These certifications form the back-bone of the OpenPGP trust-model called the Web of Trust. The name stems from the fact that the collection of certifications forms a unidirectional graph resembling a web. Each edge of the graph connects the signing certificate to the identity component associated with another certificate. -Third-party certifications are published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, as a side effect of this approach, it's feasible to reconstruct the entire social graph of all people issuing certifications. The certification's signature creation time can be used to deduct whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with. +OpenPGP software can inspect that graph. Based on the certification data in the graph and a set of trust anchors, it can infer whether a target certificate is legitimate. + +The trust anchor is usually the certificate holder's own key, but a user may designate additional certificates of organizations they are connected to as trust anchors. + +Third-party certifications can be published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, a side effect of this approach is that it's feasible to reconstruct the entire social graph of all people issuing certifications. In addition, the signature creation time of certifications can be used to deduce whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with. + +So, there is some tension between the goals of + +- a decentralized system where every participant can access certification information and perform analysis on it locally, +- privacy related goals (also [see above](email-lookup), in the comparison of email-based certificate lookup mechanisms, which also touches on this theme). (unbound_user_ids)= ### Adding unbound User IDs to a certificate From ff50c5046053b2f013255b061691d25ec45133e5 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 18:44:56 +0100 Subject: [PATCH 33/68] ch4: local user ids --- book/source/04-certificates.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 7d36807..60a4388 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -581,13 +581,14 @@ So, there is some tension between the goals of - privacy related goals (also [see above](email-lookup), in the comparison of email-based certificate lookup mechanisms, which also touches on this theme). (unbound_user_ids)= -### Adding unbound User IDs to a certificate +### Adding unbound, local, User IDs to a certificate Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). [PET]: https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model -Sequoia additionally certifies these foreign User IDs with the local trust root to facilitate authentication of certificates but marks all this additional signatures with a Non Exportable subpacket so that they are not visible when publishing the certificate e.g. on keyservers. +Sequoia additionally certifies these "local, third party, User IDs" with a local trust root to facilitate local authentication decisions. +To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable. (cert-flooding)= ### Third-party certification flooding From be36e09fd07d72e4945d8b64e179726173e35ab6 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 28 Nov 2023 19:10:26 +0100 Subject: [PATCH 34/68] ch4: flooding --- book/source/04-certificates.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 60a4388..d3fe5e6 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -544,11 +544,7 @@ Different mechanisms allow certificate lookup by email, for example: - The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs) - Traditional-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) -Their properties differ: - -- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. -- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. -- *Traditional keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). +Their properties differ, also see {ref}`distribution`. [^hip1]: @@ -578,7 +574,7 @@ Third-party certifications can be published as part of the target certificate to So, there is some tension between the goals of - a decentralized system where every participant can access certification information and perform analysis on it locally, -- privacy related goals (also [see above](email-lookup), in the comparison of email-based certificate lookup mechanisms, which also touches on this theme). +- privacy related goals (also see {ref}`email-lookup`, for a comparison of certificate distribution mechanisms, which also touches on this theme). (unbound_user_ids)= ### Adding unbound, local, User IDs to a certificate @@ -590,9 +586,20 @@ Some OpenPGP subsystems may add User IDs to a certificate, which are not bound t Sequoia additionally certifies these "local, third party, User IDs" with a local trust root to facilitate local authentication decisions. To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable. +(distribution)= +### Certificate distribution mechanisms + +Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space: + +- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. +- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. +- *Traditional keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). + (cert-flooding)= ### Third-party certification flooding +Traditional OpenPGP keyservers are one mechanism for [collection and distribution](distribution) of certificate information. Their model revolves around receiving certificate information from sources that don't identify themselves to the keyserver network. Traditionally, these keyservers have accepted both components bound to certificates by self-signatures, and third party identity certifications. + While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks. Without any restrictions in place, malicious entities can flood a certificate with excessive certifications. Called "certificate flooding," this form of digital vandalism grossly expands the certificate size, making the certificate cumbersome and impractical for users. @@ -600,9 +607,3 @@ Without any restrictions in place, malicious entities can flood a certificate wi It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation. The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019. - -TODO: merge in text from ch8: - -```text -However, in systems that unconditionally accept these certifications, it can lead to unintended consequences. Specifically, this approach has been exploited to cause denial-of-service attacks through [certificate flooding](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), a problem notably experienced by the SKS network of OpenPGP servers. -``` From 0b8e844a97357c62dcec574fbc5de0c8fd95b5ed Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 29 Nov 2023 11:31:44 +0100 Subject: [PATCH 35/68] ch4a: edit --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index d3fe5e6..cea5383 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -354,7 +354,7 @@ On the other hand, if the subkey was merely retired, and the certificate holder OpenPGP certificates act as *append-only data structures*, in practice. By this, we mean that packets that are associated with a certificate cannot be "recalled", once they were published. Third parties (such as other users, or keyservers) may keep and/or distribute copies of those packets. -While it is not possible to "remove" elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate. +While it is not possible to *remove* elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate. Invalidation resembles removal of a component in a semantical sense. The component is not a valid element of the certificate anymore, at least starting from some point in time. Implementations that handle the certificate may omit the invalid component in their representation. From 873c620241652c17438e7b1a6b935f2a03ce3a52 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Fri, 1 Dec 2023 15:22:54 +0100 Subject: [PATCH 36/68] clarification from andrew --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index cea5383..ac5c396 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -606,4 +606,4 @@ Without any restrictions in place, malicious entities can flood a certificate wi It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation. -The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019. +The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) in 2019, causing significant changes to its operation. From b71b19c62a62d0851b2315007d864099faa1f8fe Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 20:21:23 +0100 Subject: [PATCH 37/68] normalize keyserver style naming --- book/source/04-certificates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index ac5c396..475c0a4 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -542,7 +542,7 @@ Different mechanisms allow certificate lookup by email, for example: - [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) - The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs) -- Traditional-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) +- SKS-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) Their properties differ, also see {ref}`distribution`. @@ -593,7 +593,7 @@ Different mechanisms for discovering certificates, and updating certificate data - A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. - The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. -- *Traditional keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). +- *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). (cert-flooding)= ### Third-party certification flooding From 1f5fab21db5bc241cec17f77a20ab928bfda03e7 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 22:50:37 +0100 Subject: [PATCH 38/68] More explicit comparison between hagrid and hockeypuck --- book/source/04-certificates.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 475c0a4..3bf0e6a 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -595,6 +595,8 @@ Different mechanisms for discovering certificates, and updating certificate data - The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. - *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). +One central difference between hockeypuck and hagrid (the software that runs the *keys.openpgp.org* service) is that hockeypuck distributes identity packets and third-party certifications that have indeterminate validity, while hagrid does not. + (cert-flooding)= ### Third-party certification flooding From bbb55a4c5f8845bb1670a4a9bab1aa125db21a41 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 22:45:50 +0100 Subject: [PATCH 39/68] Fix missing half sentence --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 3bf0e6a..daf8b3f 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -317,7 +317,7 @@ The expiration mechanism in OpenPGP is complemented by a mechanism to extend/ren Using the expiration mechanism is useful for two reasons: -- Expiration of a certificate reminds users of that certificate to poll for updates, for example, from a keyserver. that the certificate is not fresh and a newer version should be acquired. +- Expiration of a certificate means that it cannot be used anymore. This forces users of that certificate (or their OpenPGP software) to poll for updates for it. For example, from a keyserver. - It is a passive way for certificates to "time out," e.g., if their owner loses control over them, or isn't able to broadcast a revocation, for any reason. Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the expiration of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired. From eb782f61ba2f2fd51d67548b8f54e9e57d7b3976 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 22:52:16 +0100 Subject: [PATCH 40/68] Clarify text --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index daf8b3f..2f6f6ff 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -320,7 +320,7 @@ Using the expiration mechanism is useful for two reasons: - Expiration of a certificate means that it cannot be used anymore. This forces users of that certificate (or their OpenPGP software) to poll for updates for it. For example, from a keyserver. - It is a passive way for certificates to "time out," e.g., if their owner loses control over them, or isn't able to broadcast a revocation, for any reason. -Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the expiration of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired. +Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the [*signature expiration time*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#signature-expiration-subpacket) subpacket of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired. #### Revocation From d59330a08df3999734ac218f3350541c656a5098 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 22:59:22 +0100 Subject: [PATCH 41/68] typo fix --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 2f6f6ff..b00799d 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -592,7 +592,7 @@ To prevent accidental publication of these local User IDs (e.g. to public keyser Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space: - A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. -- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only published identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. +- The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only publishes identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. - *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). One central difference between hockeypuck and hagrid (the software that runs the *keys.openpgp.org* service) is that hockeypuck distributes identity packets and third-party certifications that have indeterminate validity, while hagrid does not. From 8712e97f8e9b736d86b7ea6caf8a86f47276c10c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 23:16:20 +0100 Subject: [PATCH 42/68] fix terminology --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index b00799d..c537fec 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -347,7 +347,7 @@ By contrast, a soft revocation leaves the revoked component or signature valid b Hard revocations address the following problem: If a private key was compromised, then the attacker can issue signatures using that key. This means, the attacker could issue a signature dated before the revocation, impersonating the owner of the key. A recipient of that signature would mistakenly consider this signature valid if the issuing key has been soft revoked. This is a problem. To counteract this problem, it is reasonable to clearly mark compromised keys as suspect at any point in time. That's what hard revocations do. -On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still correct. +On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still valid. (append-only)= ### Certificates are effectively append-only data structures From 100e50b42d3ae6fbd8be0ca05150f2e45ca20236 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 23:29:56 +0100 Subject: [PATCH 43/68] link for WKD --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index c537fec..f3e221a 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -362,7 +362,7 @@ We have to distinguish the "packet level" information about a certificate from a #### Reasoning about append-only properties in a distributed system -OpenPGP is a thoroughly distributed system. Users can obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, WKD and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). +OpenPGP is a thoroughly distributed system. Users can obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). User's OpenPGP software may obtain different views of a particular certificate, over time. These systems have to reconcile and store a combined version of the possibly disparate elements they may obtain from different sources. From f142aa73e23cc1bf29067f8b2f8e9985c79aac6f Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 3 Dec 2023 23:37:01 +0100 Subject: [PATCH 44/68] clarify "systems" --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index f3e221a..af1a703 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -364,7 +364,7 @@ We have to distinguish the "packet level" information about a certificate from a OpenPGP is a thoroughly distributed system. Users can obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). -User's OpenPGP software may obtain different views of a particular certificate, over time. These systems have to reconcile and store a combined version of the possibly disparate elements they may obtain from different sources. +Different users' OpenPGP software may obtain different views of a particular certificate, over time. Individual users' OpenPGP instances have to reconcile and store a combined version of the possibly disparate elements they obtain from different sources. In practice, this means that various OpenPGP users may have differing views of any given certificate. For various reasons, not all users will be in possession of a fully up-to date and complete version of a certificate. From 68b9d2b04d58dde22a8f33135be8554939b72919 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 4 Dec 2023 00:00:34 +0100 Subject: [PATCH 45/68] move example minimization to a footnote, supplement main text with a more general paragraph --- book/source/04-certificates.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index af1a703..1168fb7 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -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 From 1dfe9001870aca96f8fcf0e8dce2a7c9c70171d6 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 4 Dec 2023 00:04:06 +0100 Subject: [PATCH 46/68] clarify --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 1168fb7..0c0a087 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -479,7 +479,7 @@ Many certificates can be significantly pruned if the only goal of distributing t 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. -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. +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 verifying the authenticity of the certificate. [^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: From 46a6ee1b3971f71493a50e2b33db7576116adea3 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 4 Dec 2023 00:10:15 +0100 Subject: [PATCH 47/68] clean up some more --- book/source/04-certificates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0c0a087..c63a4ce 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -475,13 +475,13 @@ 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. -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]. +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 (which are irrelevant to email), shadowed self-signatures, and third-party certifications. With many real-world certificates, the space savings of such a minimization are significant[^space-example]. 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. 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 verifying the authenticity of the certificate. -[^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: +[^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), authentication subkeys, and any third-party certifications: ```sh gpg --export-options export-minimal,export-clean,no-export-attributes \ From b058afec44aa3edf03c985ef2e3ba14a1ce70d44 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 4 Dec 2023 00:15:01 +0100 Subject: [PATCH 48/68] improve "pitfalls of minimization" text --- book/source/04-certificates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index c63a4ce..2e750d7 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -496,8 +496,8 @@ However, in a different context, the same certificate might be fetched to verify Disadvantages/risks of minimizing certificates: -- Does not present a 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. +- A minimized certificate does not present a full view of how it (and the validity of its components) evolved over time. +- As an OpenPGP instance learns about more certificates, third-party certifications that were previously unusable may become usable. Dropping third-party certifications by unknown issuers 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. From bd700e031342d08f5f7693d4d68649f279cbfbf0 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 4 Dec 2023 00:20:22 +0100 Subject: [PATCH 49/68] add link to schuermann-usenix2016.pdf --- book/source/04-certificates.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 2e750d7..055547e 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -525,7 +525,9 @@ For example, in workflows to accept a certificate for a communication partner, o The OpenPGP version 6 standard uses 32 byte (256 bit) fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows. -Instead, "mechanical fingerprint transfer and comparison" should be preferred, wherever possible. The reasoning is that humans tend to be bad at comparing high-entropy data (in addition, many users are probably put off by being asked to compare long hexadecimal strings). +Instead, "mechanical fingerprint transfer and comparison" should be preferred, wherever possible. The reasoning is that humans tend to be bad at comparing high-entropy data[^schuermann] (in addition, many users are probably put off by being asked to compare long hexadecimal strings). + +[^schuermann]: See "An Empirical Study of Textual Key-Fingerprint Representations" #### Use of Fingerprints and Key IDs in APIs From 9ece6aa5786da6dac149f79bba173c14098b8e21 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 4 Dec 2023 00:33:48 +0100 Subject: [PATCH 50/68] add another point to "minimization guidelines" --- book/source/04-certificates.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 055547e..d470156 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -505,7 +505,8 @@ Disadvantages/risks of minimizing certificates: #### Guidelines 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. +2. When minimizing a certificate, minimize it in a way that suites your use-case. E.g., when minimizing a certificate for distribution alongside a signed software packet, make sure to include enough historical self-signatures as to not break the verification of the signed packet. +3. When presenting a minimized certificate view, consider when that view needs to be updated. Ideally, minimized certificates are freshly generated, on demand (e.g., an Autocrypt header is constructed while an email is sent or composed). The receiver is expected to typically merge all data it sees, locally. ### Fingerprints and beyond: "Naming" certificates in user-facing contexts From 53eb8de0d9c8a6262c68071aa9bada4d478a6fd2 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Tue, 5 Dec 2023 23:36:26 +0100 Subject: [PATCH 51/68] add footnote about privately held certifications --- book/source/04-certificates.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index d470156..b658093 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -385,7 +385,9 @@ When thinking about edge cases, it's useful to "assume the worst." For example: #### Differing "views" of a certificate exist -Another way to think about this discussion is that different OpenPGP users may have a different view of any certificate. There is a notional "canonical" version of the certificate, but we cannot assume that every user has exactly this copy. Besides propagation of elements that the certificate holder has linked to a certificate, third-party certifications are by design a distributed mechanism. A third-party certification is issued by a third party, and may or may not be distributed widely by them, or by the certificate holder. Not distributing third-party certifications widely is a workflow that may be entirely appropriate for some use cases. +Another way to think about this discussion is that different OpenPGP users may have a different view of any certificate. There is a notional "canonical" version of the certificate, but we cannot assume that every user has exactly this copy. Besides propagation of elements that the certificate holder has linked to a certificate, third-party certifications are by design a distributed mechanism. A third-party certification is issued by a third party, and may or may not be distributed widely by them, or by the certificate holder. Not distributing third-party certifications widely is a workflow that may be entirely appropriate for some use cases[^tpc-privacy]. + +[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`metadata_graph`. As a general tendency, it is desirable for OpenPGP users to have the most complete possible view of all certificates that they interact with. @@ -564,6 +566,7 @@ Once the expiration time is reached, third parties, or ideally their OpenPGP sof After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached. +(metadata_graph)= ### Metadata leak of Social Graph Third-party certifications are signatures over identity components made by other certificates. From eca2183a08ae79058f2278e73a017d63782f3610 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 00:31:13 +0100 Subject: [PATCH 52/68] add autocrypt intro --- book/source/04-certificates.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index b658093..62f6c6c 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -465,6 +465,10 @@ To deal with this reality, the rpm-sequoia implementation was adjusted to accept #### Autocrypt +The [Autocrypt](https://autocrypt.org/) project describes itself as: + +> [..] a set of guidelines for developers to achieve convenient end-to-end-encryption of e-mails. It specifies how e-mail programs negotiate encryption capabilities using regular e-mails. + 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. 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. From 3e85beb41ad3fb08f3f70d275c61576752de921c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 01:39:55 +0100 Subject: [PATCH 53/68] edits for clarity, based on comments by david --- book/source/04-certificates.md | 35 +++++++++++++++++++--------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 62f6c6c..1dea90d 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -311,7 +311,7 @@ The validity of the signatures that link a certificate is a necessary preconditi Certificates and components can "expire," which renders them invalid. Each component of a certificate can have an expiration time, or be unlimited in its temporal validity. -The OpenPGP software of a sender will refuse to encrypt email to an expired certificate, or to an encryption component key that is expired. The sender's software rejects encryption to the key, essentially as a courtesy to the certificate owner, respecting the preferences expressed in their certificate metadata. +The OpenPGP software of a sender will refuse to encrypt email using an expired certificate, or using an encryption component key that is expired. The sender's software rejects encryption to the key, essentially as a courtesy to the certificate owner, respecting the preferences expressed in their certificate metadata. The expiration mechanism in OpenPGP is complemented by a mechanism to extend/renew expiration time. @@ -340,19 +340,19 @@ Some libraries, such as Sequoia PGP, expose these distinct reasons for users, en Of the defined revocation types, *Key is superseded*, *Key is retired* and *User ID is no longer valid* are considered "soft" revocations. Any other reason (including a missing *reason for revocation* subpacket) means that the revocation is "hard." -The distinction between hard and soft revocations plays a role when evaluating the validity of a component or signature at a specified reference time: Hard revocations have unbounded [temporal validity](temporal-validity), they are in effect even before their creation time. Hard revocations invalidate the revoked component or signature at all points in time. +The distinction between hard and soft revocations plays a role when evaluating the validity of a component or signature at a specified reference time: Hard revocations have unbounded [temporal validity](temporal-validity), they are in effect even before their creation time and therefore invalidate the revoked component or signature at all points in time. By contrast, a soft revocation leaves the revoked component or signature valid before the creation time of the revocation signature. A soft revocation can technically be overridden, for example, with a newer binding signature. Hard revocations address the following problem: If a private key was compromised, then the attacker can issue signatures using that key. This means, the attacker could issue a signature dated before the revocation, impersonating the owner of the key. A recipient of that signature would mistakenly consider this signature valid if the issuing key has been soft revoked. This is a problem. To counteract this problem, it is reasonable to clearly mark compromised keys as suspect at any point in time. That's what hard revocations do. -On the other hand, if the subkey was merely retired, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still valid. +On the other hand, if the subkey was merely retired using a soft revocation, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still valid. (append-only)= ### Certificates are effectively append-only data structures -OpenPGP certificates act as *append-only data structures*, in practice. By this, we mean that packets that are associated with a certificate cannot be "recalled", once they were published. Third parties (such as other users, or keyservers) may keep and/or distribute copies of those packets. +OpenPGP certificates act as *append-only data structures*, in practice. Packets that are associated with a certificate cannot be "recalled", once they were published. Third parties (such as other users, or keyservers) may keep and/or distribute copies of those packets. While it is not possible to *remove* elements, once they were publicly associated with an OpenPGP certificate, it is possible to invalidate them by adding new metadata to the certificate. This new metadata could set an *expiration time* on a component, or explicitly *revoke* that component. In both cases, no packets are removed from the certificate. @@ -381,7 +381,7 @@ However, such mitigations by definition cannot address all possible cases of out When thinking about edge cases, it's useful to "assume the worst." For example: - Recipients may not obtain updates to a certificate in a timely manner (this could happen for various reasons, including, but not limited to, interference by malicious actors). -- Data associated with a certificate may compound, and can become too large for convenient handling. If such a problem arises, then by definition, the certificate holder cannot address it: recall that the certificate holder cannot "recall" existing packets. +- Data associated with a certificate may compound, and a certificate can become too large for convenient handling, even in the course of normal operations. If such a problem arises, then by definition, the certificate holder cannot address it: remember that the certificate holder cannot "recall" existing packets. #### Differing "views" of a certificate exist @@ -397,7 +397,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 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. +For example, Bob's OpenPGP software 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). @@ -413,10 +413,10 @@ For information that *is* related to the certificate, but not bound to it by a s Certificate minimization is the practice of presenting a partial view of a certificate by filtering out some of its components. -Filtering out some elements of a certificate can have different benefits: +Filtering out some elements of a certificate can serve various purposes: -- 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. +- Omitting unnecessary components for specific use-cases. For example, email clients need encryption, signing and certification component keys, but not authentication subkeys, which are used, e.g., for SSH connections. +- Omitting third-party certifications if they are not required for a use-case. ["Certificate flooding,"](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) for example, can lead to consumer software rejecting a certificate entirely. Filtering out third-party User ID certifications on import can mitigate this. - Sometimes, a certificate organically grows so big that the user software [has problems handling it](https://www.reddit.com/r/GnuPG/comments/bp23p4/my_key_is_too_large/). #### Elements that can be omitted as part of a minimization process @@ -477,7 +477,7 @@ Basic encrypted email functionality requires only a small subset of the recipien #### Minimization for email -Note that it's not generally clear if minimization brings more benefit than harm. +Note that minimization of certificates isn't generally "right" or "wrong." The benefit or harm depends on the context. For example, we might consider minimizing a certificate for distribution via WKD, with the use-case of email in mind. @@ -485,7 +485,7 @@ Many certificates can be significantly pruned if the only goal of distributing t 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. -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 verifying the authenticity of the certificate. +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 validating the authenticity of the certificate. [^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), authentication subkeys, and any third-party certifications: @@ -504,15 +504,15 @@ Disadvantages/risks of minimizing certificates: - A minimized certificate does not present a full view of how it (and the validity of its components) evolved over time. - As an OpenPGP instance learns about more certificates, third-party certifications that were previously unusable may become usable. Dropping third-party certifications by unknown issuers 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. +- An OpenPGP implementation that minimizes a certificate might remove component keys that it cannot use itself (e.g. because it doesn't support the algorithm of that key), even if the *receiving* implementation 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. +- 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, but retain at least one subkey, even if all subkeys are expired. Although this may leave only an expired encryption subkey in the certificate, this presents a better UX for the end-user who potentially is still in possession of the private key for decryption. #### Guidelines 1. Don't minimize certificates unless you have a good reason to. 2. When minimizing a certificate, minimize it in a way that suites your use-case. E.g., when minimizing a certificate for distribution alongside a signed software packet, make sure to include enough historical self-signatures as to not break the verification of the signed packet. -3. When presenting a minimized certificate view, consider when that view needs to be updated. Ideally, minimized certificates are freshly generated, on demand (e.g., an Autocrypt header is constructed while an email is sent or composed). The receiver is expected to typically merge all data it sees, locally. +3. When presenting a minimized view of a certificate to a consumer, consider when that a new version of that view needs to be generated. Ideally, minimized certificates are freshly generated on demand (e.g., an Autocrypt header is constructed while an email is sent or composed). The receiver is expected to typically merge all data it sees locally. ### Fingerprints and beyond: "Naming" certificates in user-facing contexts @@ -526,7 +526,12 @@ This section outlines the various ways in which certificates can be named, and t With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte (160 bit) *fingerprints* as an identifier for the certificate. Or alternatively, the 8 byte (64 bit) *Key ID* variant 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. Users were asked to manually verify that the fingerprint corresponds to the expected certificate. +Workflows such as + +- accepting a certificate for a communication partner, or +- issuing a third-party certification for an identity, + +required users to manually compare the 40 character long hexadecimal representation of a fingerprint against a reference source for that fingerprint. #### Fingerprints in Version 6 From 1d5010f55ce5494c853bc6f9ffb15455a7d0f189 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 15:51:03 +0100 Subject: [PATCH 54/68] Move footnote text --- book/source/04-certificates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 1dea90d..1df8625 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -562,8 +562,6 @@ Different mechanisms allow certificate lookup by email, for example: Their properties differ, also see {ref}`distribution`. -[^hip1]: - (cert-freshness)= ### Certificate freshness: Triggering updates with an expiration time @@ -612,6 +610,8 @@ Different mechanisms for discovering certificates, and updating certificate data - The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only publishes identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. - *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). +[^hip1]: + One central difference between hockeypuck and hagrid (the software that runs the *keys.openpgp.org* service) is that hockeypuck distributes identity packets and third-party certifications that have indeterminate validity, while hagrid does not. (cert-flooding)= From a23f65282b49a07139f56ef086a793265b9e56b2 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 10:47:53 +0100 Subject: [PATCH 55/68] input from david --- book/source/04-certificates.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 1df8625..e23dbbf 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -381,7 +381,7 @@ However, such mitigations by definition cannot address all possible cases of out When thinking about edge cases, it's useful to "assume the worst." For example: - Recipients may not obtain updates to a certificate in a timely manner (this could happen for various reasons, including, but not limited to, interference by malicious actors). -- Data associated with a certificate may compound, and a certificate can become too large for convenient handling, even in the course of normal operations. If such a problem arises, then by definition, the certificate holder cannot address it: remember that the certificate holder cannot "recall" existing packets. +- Data associated with a certificate may compound, and a certificate can become too large for convenient handling, even in the course of normal operations (for example, a certificate may receive very many legitimate third-party certifications). If such a problem arises, then by definition, the certificate holder cannot address it: remember that the certificate holder cannot "recall" existing packets. #### Differing "views" of a certificate exist @@ -560,7 +560,7 @@ Different mechanisms allow certificate lookup by email, for example: - The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs) - SKS-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software) -Their properties differ, also see {ref}`distribution`. +Their properties differ, for more see {ref}`distribution`. (cert-freshness)= ### Certificate freshness: Triggering updates with an expiration time @@ -582,7 +582,7 @@ These certifications form the back-bone of the OpenPGP trust-model called the We OpenPGP software can inspect that graph. Based on the certification data in the graph and a set of trust anchors, it can infer whether a target certificate is legitimate. -The trust anchor is usually the certificate holder's own key, but a user may designate additional certificates of organizations they are connected to as trust anchors. +The trust anchor is usually the certificate holder's own key, but a user may designate additional certificates of entities they are connected to as trust anchors. Third-party certifications can be published as part of the target certificate to facilitate the process of certificate authentication. Unfortunately, a side effect of this approach is that it's feasible to reconstruct the entire social graph of all people issuing certifications. In addition, the signature creation time of certifications can be used to deduce whether the certificate owner attended a Key Signing Party (and if it was public, where it was held) and whom they interacted with. @@ -594,7 +594,7 @@ So, there is some tension between the goals of (unbound_user_ids)= ### Adding unbound, local, User IDs to a certificate -Some OpenPGP subsystems may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). +Some OpenPGP software may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). [PET]: https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/#an-address-book-style-trust-model @@ -606,7 +606,7 @@ To prevent accidental publication of these local User IDs (e.g. to public keyser Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space: -- A *Web Key Directory* service is operated by the entity that controls the domain name of the email in question. This means that WKD is decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. +- A *Web Key Directory* service is based on a well-known location on a webserver, serving certificates in a specific format. A WKD server is operated by the entity that controls the DNS domain of an email-based identity of a certificate. This means that WKD is inherently decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. - The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only publishes identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. - *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). From e6d8dccc7c7ead026743315fdc437144dbcc02fe Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 17:38:52 +0100 Subject: [PATCH 56/68] adjust sks text --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index e23dbbf..ec617f5 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -608,7 +608,7 @@ Different mechanisms for discovering certificates, and updating certificate data - A *Web Key Directory* service is based on a well-known location on a webserver, serving certificates in a specific format. A WKD server is operated by the entity that controls the DNS domain of an email-based identity of a certificate. This means that WKD is inherently decentralized, and the reliability of OpenPGP certificates may vary depending on the organization that operates a particular WKD instance. - The *keys.openpgp.org* service is a "verifying" keyserver: the keyserver software only publishes identity components (which include email addresses) after sending a verification email to that address, and receiving opt-in consent by the user of the email address. This service makes a different tradeoff: it is centralized, and relying on it to correctly perform the verification step requires trust in the operator. The tradeoff allows the service to only list identity information with the consent of the owner of that identity, and to prevent "enumeration" of the certificates and identities it stores (that is: third parties cannot obtain a list of email addresses in the service's database). By design, this service allows easy publication of revocations without requiring publication of any identity components. -- *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification (TODO: does the network handle third party signatures? If so, how?[^hip1]). +- *SKS-style keyservers* act as a distributed synchronizing database, which accepts certificate information without verification. The SKS network handles third-party signatures, additional changes to their handling are pending[^hip1]. [^hip1]: From 0e4997f049be7dd869127fe6748edbf0994cd1e7 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 17:36:48 +0100 Subject: [PATCH 57/68] adjust gnupg import tps stripping text --- book/source/04-certificates.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index ec617f5..a8ed896 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -439,9 +439,7 @@ Separately, third-party certifications are currently filtered out by the service ##### GnuPG -GnuPG [strips some signatures on key import](https://dev.gnupg.org/T4607#127792). - -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: +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.* @@ -451,6 +449,10 @@ In addition, GnuPG offers two explicit methods for certificate minimization, des `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. +Independently, GnuPG by default [strips some signatures on key import](https://dev.gnupg.org/T4607#127792)[^gpg-default-strip]. However, a number of Linux distributions change this default behavior, and continue to import signatures without minimization by default. e.g. [Debian](https://dev.gnupg.org/T4628#128513) and Arch Linux. + +[^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding](cert-flooding) event. + #### 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. From 90243e99303d6c9294a1c91ce97a5c6ffa1d4d20 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 20:08:18 +0100 Subject: [PATCH 58/68] outline koo; add 1pa3pc --- book/source/04-certificates.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index a8ed896..af0da2b 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -628,3 +628,27 @@ Without any restrictions in place, malicious entities can flood a certificate wi It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation. The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html) in 2019, causing significant changes to its operation. + +```{note} +The *keys.openpgp.org* (KOO) service performs a similar function as the SKS-style keyservers. +However, there are major differences in its design and tradeoffs. + +The KOO keyserver was designed to: + +1. conform to [GDPR regulations](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation), and +2. be resistant to flooding-style vandalism. + +To achieve these goals, KOO does not serve identitiy components at all, unless an explicit opt-in has been performed, using a confirmation process vial email. Third-party certifications are also not served by default, but only under very specific circumstances, which preclude flooding. +``` + +### First-party attestation of third-party signatures (1pa3pc) + +First-party attestation of third-party signatures (1pa3pc) was designed as a mechanism for flooding-proof distribution of third-part certifications. + +TODO + +#### Support + +The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3). + +The Hockeypuck keyserver software [plans to add support for *1pa3pc*](https://github.com/hockeypuck/hockeypuck/issues/136#issuecomment-1812466084) in version 2.2.0. \ No newline at end of file From 31b62a09af921a873e26623b1743aae592d436ce Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 20:59:44 +0100 Subject: [PATCH 59/68] more 1pa3pc --- book/source/04-certificates.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index af0da2b..710342f 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -641,14 +641,18 @@ The KOO keyserver was designed to: To achieve these goals, KOO does not serve identitiy components at all, unless an explicit opt-in has been performed, using a confirmation process vial email. Third-party certifications are also not served by default, but only under very specific circumstances, which preclude flooding. ``` -### First-party attestation of third-party signatures (1pa3pc) +### First-Party attested third-party certifications in OpenPGP (1pa3pc) -First-party attestation of third-party signatures (1pa3pc) was designed as a mechanism for flooding-proof distribution of third-part certifications. +[First-Party attested third-party certifications in OpenPGP](https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/) are a "mechanism to allow the owner of a certificate to explicitly approve of specific third-party certifications". 1pa3pc was designed to enable flooding-proof distribution of third-part certifications. -TODO +This mechanism uses the *attested certifications* signature subpacket (type ID `37`), which currently only exists as a proposed feature in [draft-ietf-openpgp-rfc4880bis](https://www.ietf.org/archive/id/draft-ietf-openpgp-rfc4880bis-10.html#table-3)[^ac-draft]. + +[^ac-draft]: Introducing the *attested certifications* signature subpacket (type ID `37`) was unfortunately not in scope of the chartered topics for the current "crypto-refresh" work of the OpenPGP working group. However, hopefully the working group can handle this feature in future rechartering. #### Support -The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3). +- The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3). -The Hockeypuck keyserver software [plans to add support for *1pa3pc*](https://github.com/hockeypuck/hockeypuck/issues/136#issuecomment-1812466084) in version 2.2.0. \ No newline at end of file +- The Hockeypuck keyserver software [plans to add support for *1pa3pc*](https://github.com/hockeypuck/hockeypuck/issues/136#issuecomment-1812466084) in version 2.2.0. + +- The Sequoia `sq` commandline tool [allows adding](https://man.archlinux.org/man/sq-key-attest-certifications.1) attested third-party certifications to a certificate. From c1455ade731ffdbc294329228fa2ab93e60412e9 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 21:54:57 +0100 Subject: [PATCH 60/68] hockeypuck note --- book/source/04-certificates.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 710342f..d7b3c03 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -641,6 +641,12 @@ The KOO keyserver was designed to: To achieve these goals, KOO does not serve identitiy components at all, unless an explicit opt-in has been performed, using a confirmation process vial email. Third-party certifications are also not served by default, but only under very specific circumstances, which preclude flooding. ``` +#### Hockeypuck-based keyservers + +Currently, third-party certification flooding can be worked around by users or administrators requesting the removal/re-adding of a certificate. [See here](https://github.com/hockeypuck/hockeypuck/wiki/HIP-1:-Regaining-control-over-public-key-identity-with-authenticated-key-management). + +Additional mechanisms [are upcoming](1pc3pc-support). + ### First-Party attested third-party certifications in OpenPGP (1pa3pc) [First-Party attested third-party certifications in OpenPGP](https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/) are a "mechanism to allow the owner of a certificate to explicitly approve of specific third-party certifications". 1pa3pc was designed to enable flooding-proof distribution of third-part certifications. @@ -649,6 +655,7 @@ This mechanism uses the *attested certifications* signature subpacket (type ID ` [^ac-draft]: Introducing the *attested certifications* signature subpacket (type ID `37`) was unfortunately not in scope of the chartered topics for the current "crypto-refresh" work of the OpenPGP working group. However, hopefully the working group can handle this feature in future rechartering. +(1pc3pc-support)= #### Support - The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3). From c6137f43e267b8f4cccd10b57470b3391d2d981a Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 6 Dec 2023 22:01:44 +0100 Subject: [PATCH 61/68] punctuation --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index d7b3c03..18f20b9 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -594,7 +594,7 @@ So, there is some tension between the goals of - privacy related goals (also see {ref}`email-lookup`, for a comparison of certificate distribution mechanisms, which also touches on this theme). (unbound_user_ids)= -### Adding unbound, local, User IDs to a certificate +### Adding unbound, local User IDs to a certificate Some OpenPGP software may add User IDs to a certificate, which are not bound to the primary key by the certificate's owner. This can be useful to store local identity information (e.g., Sequoia's public store attaches ["pet-names"][PET] to certificates, in this way). From 54f0bb31e4715ff371a1d7053083f970fb5e6049 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 12:02:07 +0100 Subject: [PATCH 62/68] fix suggested by paul --- book/source/04-certificates.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 18f20b9..1e8110f 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -326,9 +326,11 @@ Component keys use *Key Expiration Time* subpackets for expressing the expiratio Since OpenPGP certificates act as ["append only" data structures](append-only), existing components or signatures cannot simply be "removed." Instead, they can be marked as invalid by issuing revocation signatures. These additional revocation signatures are added to the certificate. -Each component, such as User ID and a subkey, may be revoked without affecting the rest of the certificate. +Each component, such as User ID and a subkey, can be revoked without affecting the rest of the certificate. -Revoking the primary key with a [*Key revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) (type ID `0x20`) is a special case: This marks the entire certificate, including all of its components unusable. +The *primary User ID* is an exception: when it is revoked, the entire certificate is considered invalid. + +Revoking the primary key with a [*Key revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) (type ID `0x20`) also marks the entire certificate, including all of its components, as invalid and unusable. #### Semantics of Revocations From d899a69b21c6ab073837788ffae40e585ac782ff Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 12:22:48 +0100 Subject: [PATCH 63/68] spell out minimize-on-import concern --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 1e8110f..49d72f2 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -451,7 +451,7 @@ GnuPG offers two explicit methods for certificate minimization, described [in th `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. -Independently, GnuPG by default [strips some signatures on key import](https://dev.gnupg.org/T4607#127792)[^gpg-default-strip]. However, a number of Linux distributions change this default behavior, and continue to import signatures without minimization by default. e.g. [Debian](https://dev.gnupg.org/T4628#128513) and Arch Linux. +Independently, GnuPG by default [strips some signatures on key import](https://dev.gnupg.org/T4607#127792)[^gpg-default-strip]. However, a number of Linux distributions change this default behavior, and continue to import signatures without minimization by default. e.g. [Debian](https://dev.gnupg.org/T4628#128513) and Arch Linux: stripping third-party certifications on import, by default, is problematic for users who want to leverage authentication based on the [Web of Trust mechanism](wot). [^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding](cert-flooding) event. From 2a2d0cd2d972dfca88dce1a1ba9b531cda3ebedd Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 12:43:09 +0100 Subject: [PATCH 64/68] clean up term --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 49d72f2..a7df3e7 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -580,7 +580,7 @@ After the update, the updated copy of the certificate will usually have a fresh (metadata_graph)= ### Metadata leak of Social Graph -Third-party certifications are signatures over identity components made by other certificates. +Third-party certifications are signatures over identity components made by other users. These certifications form the back-bone of the OpenPGP trust-model called the Web of Trust. The name stems from the fact that the collection of certifications forms a unidirectional graph resembling a web. Each edge of the graph connects the signing certificate to the identity component associated with another certificate. From db1160e2c5d0d09362ad3048ad2ebd880c900bef Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 14:28:18 +0100 Subject: [PATCH 65/68] add slight clarification --- book/source/04-certificates.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index a7df3e7..0119663 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -334,7 +334,9 @@ Revoking the primary key with a [*Key revocation signature*](https://www.ietf.or #### Semantics of Revocations -In contrast to expiration, revocation is typically final and not withdrawn. +In contrast to expiration, revocation is typically final and not withdrawn[^undo-revocations]. + +[^undo-revocations]: While some revocations can be reverted, undoing revocations is an uncommon workflow. Unlike expirations, which are commonly undone by extending the expiration time. A revocation indicates that the component should not be used. Revocation signatures over components use a [*Reason for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation) subpacket to specify further details about the reason why the component or certification was revoked. The OpenPGP format specifies a set of distinct [values for *Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#table-10), and additionally provides space for a human-readable free text field for comments about the revocation. From b19099a4af1f2ef5fb2d4f64b21770207f76a17e Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 14:41:06 +0100 Subject: [PATCH 66/68] longer story: https://codeberg.org/openpgp/notes/pulls/161#issuecomment-1368213 --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0119663..c36f943 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -366,7 +366,7 @@ We have to distinguish the "packet level" information about a certificate from a #### Reasoning about append-only properties in a distributed system -OpenPGP is a thoroughly distributed system. Users can obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). +OpenPGP is a decentral and distributed system. Users can obtain and transmit certificate information about their own, as well as other users', certificates using a broad range of mechanisms. These mechanisms include keyservers, manual handling, [Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/) (WKD) and [Autocrypt](https://en.wikipedia.org/wiki/Autocrypt). Different users' OpenPGP software may obtain different views of a particular certificate, over time. Individual users' OpenPGP instances have to reconcile and store a combined version of the possibly disparate elements they obtain from different sources. From c217ed6ab44cb586f91604228b1e6e60a2b1a20c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 21:45:23 +0100 Subject: [PATCH 67/68] clarify --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index c36f943..3e97a03 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -346,7 +346,7 @@ Of the defined revocation types, *Key is superseded*, *Key is retired* and *User The distinction between hard and soft revocations plays a role when evaluating the validity of a component or signature at a specified reference time: Hard revocations have unbounded [temporal validity](temporal-validity), they are in effect even before their creation time and therefore invalidate the revoked component or signature at all points in time. -By contrast, a soft revocation leaves the revoked component or signature valid before the creation time of the revocation signature. A soft revocation can technically be overridden, for example, with a newer binding signature. +By contrast, a soft revocation leaves the revoked component or signature valid before the creation time of the revocation signature. A soft revocation can technically be overridden, for example, with a newer binding signature (the new binding signature and its metadata then shadow the revocation and re-connect and re-validate the component). Hard revocations address the following problem: If a private key was compromised, then the attacker can issue signatures using that key. This means, the attacker could issue a signature dated before the revocation, impersonating the owner of the key. A recipient of that signature would mistakenly consider this signature valid if the issuing key has been soft revoked. This is a problem. To counteract this problem, it is reasonable to clearly mark compromised keys as suspect at any point in time. That's what hard revocations do. From c2c7ad63bc27c1acaabf1723a1c422de44a9ad0d Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Thu, 7 Dec 2023 22:04:57 +0100 Subject: [PATCH 68/68] use "OpenPGP subsystem" to talk about certificate store state --- book/source/04-certificates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 3e97a03..8fbeb2c 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -509,7 +509,7 @@ However, in a different context, the same certificate might be fetched to verify Disadvantages/risks of minimizing certificates: - A minimized certificate does not present a full view of how it (and the validity of its components) evolved over time. -- As an OpenPGP instance learns about more certificates, third-party certifications that were previously unusable may become usable. Dropping third-party certifications by unknown issuers as a part of minimization prevents this mechanism. +- As the OpenPGP subsystem on a user's computer learns about more certificates, third-party certifications that were previously unusable may become usable. Dropping third-party certifications by unknown issuers as a part of minimization prevents this mechanism. - An OpenPGP implementation that minimizes a certificate might remove component keys that it cannot use itself (e.g. because it doesn't support the algorithm of that key), even if the *receiving* implementation supports them. - Refreshing certificates from key servers may inflate the certificate again, since OpenPGP certificates tend to act as [append-only structures](append-only). - 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, but retain at least one subkey, even if all subkeys are expired. Although this may leave only an expired encryption subkey in the certificate, this presents a better UX for the end-user who potentially is still in possession of the private key for decryption.