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

Normalize "expiration date" -> "expiration time"

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-11 16:20:53 +01:00
parent 40d93e3386
commit 4b14b9d2c2
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
3 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

2
book/source/09-verification.md
View file

@ -9,7 +9,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
Signature verification in the OpenPGP protocol is a complex process.
Many factors influence the validity of a signature.
Firstly, its expiration date: A signature can be valid at one point in time and expired a second later.
Firstly, its expiration time: A signature can be valid at one point in time and expired a second later.
Signatures can be invalid due to the absence or presence of other signatures (e.g., revocations).
Some signatures can be verified standalone, while others require the verification of a chain-like structure of signatures, mostly within the issuer's certificate.

2
book/source/17a-adv-certificates.md
View file

@ -87,7 +87,7 @@ There are various potential problems associated with this fact: Users may not be
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."
[^mgorny]: See, for example, [here](https://blogs.gentoo.org/mgorny/2018/08/13/openpgp-key-expiration-is-not-a-security-measure/): "Expiration times 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.

2
book/source/17b-adv-private.md
View file

@ -23,7 +23,7 @@ While private keystore operations require component keys, they do not require ac
```{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 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.
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 time.
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.
```