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

Add 'When are certificates valid'

Browse source
This commit is contained in:
Wiktor Kwapisiewicz 2023-11-24 11:22:23 +01:00 • committed by Heiko Schaefer
parent 6a14882687
commit a5f3ea98e8
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 5 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

12
book/source/04-certificates.md
View file

@ -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