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

ch4: edits to "Certificate validity" section

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-26 23:23:49 +01:00
parent 5c73827f28
commit 4794199884
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 19 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -296,13 +296,29 @@ For more on third-party {term}`certifications<Certification>`, see {ref}`third_p
### When are certificates valid?
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.
Certificates are composites of components that are linked together using [signatures](08-signing_components). Here we discuss how to determine if a certificate in its entirety, or one of its components, individually, is valid.
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 acquired. 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.
Certificate validity - discussed here - is related to [signature validity](verification_chapter), and builds on that concept.
#### Revocation
Since OpenPGP certificates are effectively an [*append only*](append-only) data structure, existing signatures are revoked by issuing revocation signatures, and adding them to the certificate.
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 indirectly makes all other components unusable.
#### Expiration
A related concept is [key expiration](#cert-freshness), which also makes the component unusable. However, 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 acquired. 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.
#### Semantics of Revocation
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.
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 shows the component as valid. But for a hard revocation, it is considered invalid at any point in time.
The distinction addresses the following attack: If a 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