vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-10 03:39:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

edit design options/variations of privarte key store systems

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-30 15:38:23 +01:00
parent 249948096c
commit 8bfb2c8bf1
1 changed files with 9 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

20
book/source/05-private.md
View file

@ -136,26 +136,24 @@ These essential operations require access only to the component keys and their a
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 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.
### Design options ### Design variations
Designs of private key subsystems in the OpenPGP space differ: The design of private key subsystems within the OpenPGP framework varies, offering different approaches to cryptographic operations:
1. Some designs perform the primitive cryptographic operations in a separate backend, only using the cryptographic key material itself. This type of design matches well with general purpose hardware cryptographic devices (such as TPMs). 1. **Separate backend operations**: Some designs execute the primitive cryptographic operations in a separate backend, using only the cryptographic key material. This approach is particularly compatible with general purpose hardware cryptographic devices, such as [trusted platform modules (TPMs)](https://en.wikipedia.org/wiki/Trusted_Platform_Module).
2. An OpenPGP private key subsystem may be built around component keys - that is, 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 include metadata, which is required for some operations. ECDH operations, in particular, require metadata as KDF parameters. 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. Keeping a copy of full TSKs in the private key subsystem, and using those for private key operations. 3. **Full transferable secret keys**: Some designs maintain copies of full TSKs in the private key subsystem, leveraging these for private key operations.
Private key store operations require component keys, but do not require access to the rest of the certificate. While private key store operations require component keys, they do not require access to the entire OpenPGP certificate.
```{note} ```{note}
Design 3, which involves keeping a copy of full TSKs in the private key subsystem can cause "split brain" problems. The third design option, involving the storage of full TSKs in the private key subsystem, can cause "split brain" problems.
For example, the private key store may contain a TSK, with outdated certificate metadata. The certificate may be considered expired, based on data in the TSK, while the copy of the same certificate in the local public key store might show an updated version where the expiration date has been extended[^tb-split]. 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.
This class of problem existed in GnuPG 1.x, which held separate copies of full TSKs in its private store component. 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.
``` ```
[^tb-split]: The current design of Thunderbird's OpenPGP subsystem can lead to users experiencing such issues.
### Two tiers ### Two tiers
At its core, an OpenPGP private key subsystem performs operations that only require the private cryptographic key material, as in design 1. At its core, an OpenPGP private key subsystem performs operations that only require the private cryptographic key material, as in design 1.