From 3b0dfd5cd76b5c4cd5b4c2ebeb693aa511cff909 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 18:14:45 +0100 Subject: [PATCH 1/8] move contextualization paragraphs up to the first block --- book/source/04-certificates.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 0e0fcc0..17451ee 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -10,6 +10,14 @@ OpenPGP fundamentally hinges on the concept of "OpenPGP certificates," also know An OpenPGP certificate, by definition, does not contain private key material. +Fundamentally, the effective management of certificates and a thorough grasp of their authentication and trust models are crucial for proficient OpenPGP usage. Although this document offers just a brief overview of these aspects, they form a fundamental part of the broader OpenPGP framework and warrant further study. + +- For an in-depth exploration of OpenPGP's private key material, refer to {ref}`private_key_chapter`. This chapter provides essential insights into private key management and security practices. + +- The bindings that link the components of a certificate are comprehensively discussed in {ref}`component_signatures_chapter`, offering a deeper understanding of certificate structure and integrity. + +- For a detailed analysis of the internal (packet) structure of certificates and keys, our chapter {ref}`zoom_certificates` can serve as an invaluable resource. + ## Terminology: Understanding "keys" The term "(cryptographic) keys" is central to grasping the concept of OpenPGP certificates. However, it can refer to different entities, making it a potentially confusing term. Let's clarify those differences. @@ -28,14 +36,6 @@ In OpenPGP, the term "key" may refer to three distinct layers, each serving a un The following section will delve into the OpenPGP-specific layers (2 and 3) to provide a clearer understanding of their roles within OpenPGP certificates. -Fundamentally, the effective management of certificates and a thorough grasp of their authentication and trust models are crucial for proficient OpenPGP usage. Although this document offers just a brief overview of these aspects, they form a fundamental part of the broader OpenPGP framework and warrant further study. - -– For an in-depth exploration of OpenPGP's private key material, refer to {ref}`private_key_chapter`. This chapter provides essential insights into key management and security practices. - -– The bindings that unify the components of a certificate are comprehensively discussed in {ref}`component_signatures_chapter`, offering a deeper understanding of certificate structure and integrity. - -– For a detailed analysis of the internal (packet) structure of certificates and keys, our chapter {ref}`zoom_certificates` can serve as an invaluable resource. - ## Structure of OpenPGP certificates An OpenPGP certificate (or "OpenPGP key") is a collection of an arbitrary number of elements[^packets]: From a4318538326607078aee0d296e00cbaebedcb097 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 18:24:36 +0100 Subject: [PATCH 2/8] zoom_certificates doesn't talk about private keys (anymore). de-emphasize the packet-level chapter (it's still very unclear to me how many readers should look at those chapters). --- 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 17451ee..7359147 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -16,7 +16,7 @@ Fundamentally, the effective management of certificates and a thorough grasp of - The bindings that link the components of a certificate are comprehensively discussed in {ref}`component_signatures_chapter`, offering a deeper understanding of certificate structure and integrity. -- For a detailed analysis of the internal (packet) structure of certificates and keys, our chapter {ref}`zoom_certificates` can serve as an invaluable resource. +- Finally, our chapter {ref}`zoom_certificates` discusses the internal structure of certificates in detail. ## Terminology: Understanding "keys" From 111f6cca41dbd39520576986d14ad3b59e274c90 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 18:38:30 +0100 Subject: [PATCH 3/8] attempt at footnote with more detail on fingerprint uniqueness. the exact content might need more tweaking. --- 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 7359147..05901dc 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -96,9 +96,11 @@ For example, an OpenPGP version 4 certificate with the fingerprint `B3D2 7B09 FB Historically, even shorter 32-bit identifiers were used, like this: `2455 4239`, or `0x24554239`. Such identifiers still appear in very old documents about PGP. However, [32-bit identifiers have been long deemed unfit for purpose](https://evil32.com/). At one point, 32-bit identifiers were called "short Key ID," while 64-bit identifiers were referred to as "long Key ID." ```{note} -In practice, the fingerprint of a component key, while not theoretically unique, functions effectively as a unique identifier. The use of a [cryptographic hash algorithm](crypto-hash) in generating fingerprints makes the occurrence of two different component keys with the same fingerprint extremely unlikely. +In practice, the fingerprint of a component key, while not theoretically unique, functions effectively as a unique identifier. The use of a [cryptographic hash algorithm](crypto-hash) in generating fingerprints makes the occurrence of two different component keys with the same fingerprint extremely unlikely[^finger-unique]. ``` +[^finger-unique]: For both OpenPGP version 6 and version 4, the likelihood of accidental occurrence of duplicate fingerprints is negligible when key material is generated based on an acceptable source of entropy. A separate question is if an attacker can purposely craft a second key with the same fingerprint as a given pre-existing component key. With the current state of the art, this is not possible for OpenPGP version 6 and version 4 keys. However, at the time of this writing, the SHA-1-based fingerprints of OpenPGP version 4 are considered insufficiently strong at protecting against the generation of pairs of key material with the same fingerprint. + ### Primary key The OpenPGP primary key is a component key that serves a distinct, central role in an OpenPGP certificate: From 4635d15ecec394571ffb984e2273028dea242184 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 18:41:35 +0100 Subject: [PATCH 4/8] drop duplication --- 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 05901dc..45e5d77 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -149,7 +149,7 @@ For further conventions on User IDs, refer to the document [draft-dkg-openpgp-us **Split User IDs** -One proposed variant for encoding identities in User IDs is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). Although currently uncommon, there are currently no significant technical barriers to implementing this format[^dkg-split]. +One proposed variant for encoding identities in User IDs is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). Although uncommon, there are currently no significant technical barriers to implementing this format[^dkg-split]. [^dkg-split]: Historically, the OpenPGP ecosystem faced challenges in this context. For further details, refer to Daniel Kahn Gillmor's January 2019 article, ["What were Separated User IDs"](https://dkg.fifthhorseman.net/blog/2019-dkg-openpgp-transition.html#what-were-separated-user-ids). From ee1e9d539618cfda0a26ff206fc6e269d5f76002 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 19:20:00 +0100 Subject: [PATCH 5/8] simplify/clarify section title --- 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 45e5d77..30f81b9 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -183,7 +183,7 @@ In very abstract terms, the primary key of a certificate acts as a root of trust By binding components using digital signatures, recipients of an OpenPGP certificate need only validate the authenticity of the primary key to use for their communication partner. Traditionally, this is done by manually verifying the *fingerprint* of the primary key. Once the validity of the primary key is confirmed, the validity of the remaining components can be automatically assessed by the user's OpenPGP software. Generally, components are valid parts of a certificate if there is a statement signed by the certificate's primary key endorsing this validity. -## Metadata capabilities, preferences, and storage +## Metadata in certificates OpenPGP certificates, their component keys, and identities possess metadata that is not stored within the components it pertains to. Instead, this metadata is stored within signature packets, which are integral to the structure of an OpenPGP certificate. From 0a2bccb380cd82c88a3e0d0a0a87fa6e75ae181a Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 19:20:42 +0100 Subject: [PATCH 6/8] generalize: User Attributes are uncommon, but we should include them --- 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 30f81b9..db334e6 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -193,7 +193,7 @@ Key attributes, such as capabilities (like *signing* or *encryption*) and expira - **Subkey metadata** is defined within the [subkey binding signature](binding_subkeys) that links the subkey to the certificate. -- **User ID metadata** is is associated via the [certifying self-signature](bind_ident) that links the identity to the certificate. +- **Identity component metadata** is associated via the [certifying self-signature](bind_ident) that links the identity (usually in the form of a User ID) to the certificate. It is crucial to note that the components of an OpenPGP certificate remain static after their creation. The use of signatures to store metadata allows for subsequent modifications without altering the original components. For instance, a certificate holder can update the expiration time of a component by issuing a new, superseding signature. From b121676a0de3ddb195251060a5eef3d50b04d7c5 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 19:26:55 +0100 Subject: [PATCH 7/8] i think "demonstrate" gestures partly in the wrong direction. much agility is already built in. the point here is not that more agility can be built in on short notice (even though that is also true). but rather that OpenPGP already allows users to make a lot of decisions about which mechanisms to use, right now. --- 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 db334e6..1a1660a 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -220,7 +220,7 @@ Notably, in many algorithms, encryption and signing-related functionalities (i.e ### Algorithm preferences and feature signaling -OpenPGP demonstrates significant ["cryptographic agility"](https://en.wikipedia.org/wiki/Cryptographic_agility). It doesn't rely on a single fixed set of algorithms. Instead, it defines a suite of cryptographic primitives from which users (or their applications) can choose. +OpenPGP incorporates significant ["cryptographic agility"](https://en.wikipedia.org/wiki/Cryptographic_agility). It doesn't rely on a single fixed set of algorithms. Instead, it defines a suite of cryptographic primitives from which users (or their applications) can choose. This agility facilitates the easy adoption of new cryptographic primitives into the standard, allowing for a seamless transition. Users can gradually migrate to new cryptographic mechanisms without disruption. From 5621dfa79cbf08606bf0542ffa8fc8780ef145d4 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 25 Nov 2023 19:29:18 +0100 Subject: [PATCH 8/8] avoid using the technical term "key" as a generic word --- 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 1a1660a..47cc2f2 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -226,7 +226,7 @@ This agility facilitates the easy adoption of new cryptographic primitives into However, this approach requires that OpenPGP software determine the cryptographic mechanisms that a set of communication partners can handle and prefer. OpenPGP employs several mechanisms for this purpose, which allow negotiation between sender and recipient. It's important to note that OpenPGP is not an online scheme; thus, this negotiation is effectively one-way. The active party interprets the preferences expressed in the certificate of the passive party. -Key negotiation mechanisms in OpenPGP include: +Negotiation mechanisms in OpenPGP include: - [Preferred hash algorithms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#preferred-hashes-subpacket) - [Preferred symmetric ciphers for v1 SEIPD](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#preferred-v1-seipd)