change key store to keystore, edit two-tier section

book/source/05-private.md

@@ -21,7 +21,7 @@ In this documentation, we treat the private key material as logically separate f
 
 ```{figure} diag/OpenPGPCert_with_privatekeystore.png
 :name: fig-openpgp-certificate-with-private-key-store
-:alt: A diagram on a white background showing an OpenPGP certificate and a private key store. Gray dotted lines connect the green public key symbols of the OpenPGP certificate to red dotted private key symbols in the private key store.
+:alt: A diagram on a white background showing an OpenPGP certificate and a private keystore. Gray dotted lines connect the green public key symbols of the OpenPGP certificate to red dotted private key symbols in the private keystore.
 
 An OpenPGP certificate, with the associated private key material handled in a separate subsystem.
 ```
@@ -51,7 +51,7 @@ The TSK format is particularly useful for backups of OpenPGP key material or tra
 Transferable secret keys are sometimes colloquially referred to as "OpenPGP private keys."
 ```
 
-Historically, the concept of TSKs, which combine all components of an OpenPGP certificate with the associated private key material, has sometimes been conflated with OpenPGP private key operations. However, it is more accurate to view TSKs as a specialized format for storage and transport, rather than as a data structure for use in a key store. For further details, see {ref}`key-store-design`.
+Historically, the concept of TSKs, which combine all components of an OpenPGP certificate with the associated private key material, has sometimes been conflated with OpenPGP private key operations. However, it is more accurate to view TSKs as a specialized format for storage and transport, rather than as a data structure for use in a keystore. For further details, see {ref}`key-store-design`.
 
 (encrypted_secrets)=
 ## Protection of private key material in OpenPGP
@@ -114,7 +114,7 @@ Hardware security devices, such as OpenPGP cards, are designed to prevent the us
 
 OpenPGP cards adhere to an open specification detailed in the [Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems, Version 3.4.1](https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.1.pdf). This specification has been implemented by multiple vendors across various devices, with several Free Software versions available, some of which are compatible with open hardware designs.
 
-Effectively, the OpenPGP card specification outlines one model for a private key store subsystem. OpenPGP cards do not store a full OpenPGP certificate. Instead, they have three distinct "key slots" designated for *signing*, *decryption*, and *authentication*. Each key slot stores the data of one component key[^missing-ecdh], including its cryptographic private key material. Additionally, OpenPGP cards explicitly store the fingerprint of each component key within the corresponding key slot.
+Effectively, the OpenPGP card specification outlines one model for a private keystore subsystem. OpenPGP cards do not store a full OpenPGP certificate. Instead, they have three distinct "key slots" designated for *signing*, *decryption*, and *authentication*. Each key slot stores the data of one component key[^missing-ecdh], including its cryptographic private key material. Additionally, OpenPGP cards explicitly store the fingerprint of each component key within the corresponding key slot.
 
 [^missing-ecdh]: In the case of ECDH keys, the KDF parameters (hash function ID and a symmetric encryption algorithm ID) are not stored on the OpenPGP card. This is considered a flaw in the OpenPGP card specification. These missing parameters can be handled in two ways by OpenPGP software on the host computer: either by consulting a copy of the component key (e.g., by inspecting a copy of the certificate) or by deducing the missing KDF parameters from the stored OpenPGP fingerprint on the card.
 
@@ -122,9 +122,9 @@ Notably, the practice of explicitly storing fingerprints on OpenPGP cards contra
 
 ## Private key operations
 
-Although OpenPGP encompasses a broad range of cryptographic mechanisms, the set of operations performed within the core of a private key store are simple and very limited.
+Although OpenPGP encompasses a broad range of cryptographic mechanisms, the set of operations performed within the core of a private keystore are simple and very limited.
 
-Specifically, an OpenPGP private key store implements two primitives:
+Specifically, an OpenPGP private keystore implements two primitives:
 
 1. Given private key material whose algorithm supports decryption, it can decrypt a *session key*.
 2. Given private key material whose algorithm supports signing, it can calculate a *cryptographic signature* for a hash digest.
@@ -132,9 +132,9 @@ Specifically, an OpenPGP private key store implements two primitives:
 These essential operations require access only to the component keys and their associated private key material, specifically [Secret-Key packets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-secret-key-packet-formats). Additional packets, such as binding signatures, are not required. 
 
 (key-store-design)=
-## Private key stores
+## Private keystores
 
-This section examines the diverse architectures and operational mechanics of private key stores in OpenPGP. It focuses on the various design choices, their functional implications, and how they contribute to the secure management of private key material.
+This section examines the diverse architectures and operational mechanics of private keystores in OpenPGP. It focuses on the various design choices, their functional implications, and how they contribute to the secure management of private key material.
 
 ### Design variations
 
@@ -144,12 +144,12 @@ The design of private key subsystems within the OpenPGP framework varies, offeri
 2. **Component key-based systems**: An OpenPGP private key subsystem may be built around component keys, specifically the content of [Secret-Key packets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-secret-key-packet-formats). These packets contain metadata that is required for some operations. ECDH operations, in particular, require metadata as KDF parameters.
 3. **Full transferable secret keys**: Some designs maintain copies of full TSKs in the private key subsystem, leveraging these for private key operations.
 
-While private key store operations require component keys, they do not require access to the entire OpenPGP certificate.
+While private keystore operations require component keys, they do not require access to the entire OpenPGP certificate.
 
 ```{note}
 The third design option, involving the storage of full TSKs in the private key subsystem, can cause "split brain" problems.
 
-For example, a private key store might contain a TSK with outdated certificate metadata, marking the certificate as expired, while the updated version in the local public key store could indicate an extended expiration date. 
+For example, a private keystore might contain a TSK with outdated certificate metadata, marking the certificate as expired, while the updated version in the local public keystore could indicate an extended expiration date. 
 
 This problem was notably present in GnuPG 1.x, which held separate TSK copies in its private store component. Similarly, the current design of Thunderbird's OpenPGP subsystem can lead to users experiencing such issues.
 ```
@@ -158,9 +158,9 @@ This problem was notably present in GnuPG 1.x, which held separate TSK copies in
 
 At its core, an OpenPGP private key subsystem performs operations requiring only the private cryptographic key material, akin to the "separate backend operations" model described above. 
 
-However, the subsystem also supports operations that require additional access to the metadata of the component key. These operations, supplementary to the core key store operations, do not involve the private key material. 
+However, the subsystem also supports operations that require additional access to the metadata of the component key. These operations, supplementary to the core keystore operations, do not involve the private key material. 
 
-When implementing a key store based on hardware cryptographic devices like [OpenPGP card](card-priv), its design will consist of two layers:
+When implementing a keystore based on hardware cryptographic devices like [OpenPGP card](card-priv), its design will consist of two layers:
 
 - **core layer**: directly handles private key material, and
 - **supplementary layer**: performs additional cryptographic operations that don't directly use the private key material, such as [AES key wrap](https://www.rfc-editor.org/rfc/rfc3394.html) for ECDH.
@@ -173,17 +173,15 @@ When implementing a key store based on hardware cryptographic devices like [Open
 
 ### Addressing individual keys
 
-An independent design question is how key material is addressed, by users of the keystore.
+A critical aspect of keystore design involves determining how users address individual key materials.
 
-The fingerprint of the individual component keys is one obvious option.
+One common method is using the fingerprint of each component key. The availability of these fingerprints, however, depends on the underlying technology of the keystore. For instance, in software-based private keystores or OpenPGP cards, fingerprints of component keys are usually directly accessible. Key stores relying on generic cryptographic hardware, like TPMs, need to implement their own mechanisms for tracking and managing the fingerprints of each key.
-
-Depending on what backs the keystore, fingerprints are readily available, such as with software private keys, or OpenPGP card devices. In other cases, the key store needs to keep track of fingerprints by itself, e.g., when based on generic cryptographic hardware such as TPM.
 
 ### Assorted other duties
 
-Additionally, a key store may want to keep track of devices that contain particular component keys. It may need to deal with secrets, such as passphrases of software keys, or PINs of OpenPGP card devices. It may need to notify the user that some interaction is required. For example, some OpenPGP card devices can require touch confirmation to authorize each cryptographic operation.
+Additionally, a keystore may want to keep track of devices that contain particular component keys. It may need to deal with secrets, such as passphrases of software keys, or PINs of OpenPGP card devices. It may need to notify the user that some interaction is required. For example, some OpenPGP card devices can require touch confirmation to authorize each cryptographic operation.
 
-### Visualizing key store operations 
+### Visualizing keystore operations 
 
 #### Signing
 
@@ -196,7 +194,7 @@ write
 ```{admonition} VISUAL
 :class: warning
 
-show examples for the operations in a private key store.
+show examples for the operations in a private keystore.
 
 - reuse the visual elements of the lowest level in the ch6 "how signatures are made" diagram (ch 6): "making a cryptographic signature from a hash digest"
 ```
@@ -212,7 +210,7 @@ write
 ```{admonition} VISUAL
 :class: warning
 
-show examples for the operations in a private key store.
+show examples for the operations in a private keystore.
 
 - once we have a visual for the low level asymmetric decryption operation (in ch11), mirror it here
 ```