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

ch4: certificate validity

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-28 15:11:18 +01:00
parent 4794199884
commit 029b774f25
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 40 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -296,29 +296,58 @@ For more on third-party {term}`certifications<Certification>`, see {ref}`third_p
### When are certificates valid?
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.
Certificates are composites of components that are linked together using [signatures](08-signing_components).
Certificate validity - discussed here - is related to [signature validity](verification_chapter), and builds on that concept.
A certificate can be valid or invalid as a whole. However, even when a certificate is valid, individual components (subkeys or identities) of it can be invalid.
#### Revocation
In this section, we discuss the validity of certificates and their components. This discussion is closely related to [signature validity](verification_chapter), and builds on that concept.
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.
The validity of the signatures that link a certificate is a necessary precondition. Two concepts are particularly central to the validity of certificates and components:
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
- Revocation
#### 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.
Certificates and components can "expire," which renders them invalid. Each component of a certificate can have an expiration time, or be unlimited in its temporal validity.
#### Semantics of Revocation
The OpenPGP software of a sender will refuse to encrypt email to an expired certificate, or to an encryption component key that is expired. The sender's software rejects encryption to the key, essentially as a courtesy to the certificate owner, respecting the preferences expressed in their certificate metadata.
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.
The expiration mechanism in OpenPGP is complemented by a mechanism to extend/renew expiration time.
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."
Using the expiration mechanism is useful for two reasons:
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.
- Expiration of a certificate reminds users of that certificate to poll for updates, for example, from a keyserver. that the certificate is not fresh and a newer version should be acquired.
- It is a passive way for certificates to "time out," e.g., if their owner loses control over them, or isn't able to broadcast a revocation, for any reason.
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.
Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the expiration of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired.
#### Revocation
Since OpenPGP certificates act as ["append only" data structures](append-only), existing components or signatures cannot simply be "removed." Instead, they can be marked as invalid by issuing revocation signatures. These additional revocation signatures are added to the certificate.
Each component, such as User ID and a subkey, may be revoked without affecting the rest of the certificate.
Revoking the primary key with a [*Key revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-revocation-signature-ty) (type ID `0x20`) is a special case: This marks the entire certificate, including all of its components unusable.
#### Semantics of Revocations
In contrast to expiration, revocation is typically final and not withdrawn.
A revocation indicates that the component should not be used. Revocation signatures over components use a [*Reason for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation) subpacket to specify further details about the reason why the component or certification was revoked. The OpenPGP format specifies a set of distinct [values for *Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#table-10), and additionally provides space for a human-readable free text field for comments about the revocation.
Some libraries, such as Sequoia PGP, expose these distinct reasons for users, enabling nuanced machine-readable statements by the revoker. Other implementations focus mainly on the distinction between "hard" and "soft" revocations.
Of the defined revocation types, *Key is superseded*, *Key is retired* and *User ID is no longer valid* are considered "soft" revocations. Any other reason (including a missing *reason for revocation* subpacket) means that the revocation is "hard."
The distinction between hard and soft revocations plays a role when evaluating the validity of a component or signature at a specified reference time: Hard revocations have unbounded [temporal validity](temporal-validity), they are in effect even before their creation time. Hard revocations invalidate the revoked component or signature at all points in time.
By contrast, a soft revocation leaves the revoked component or signature valid before the creation time of the revocation signature. A soft revocation can technically be overridden, for example, with a newer binding signature.
Hard revocations address the following problem: If a private key was compromised, then the attacker can issue signatures using that key. This means, the attacker could issue a signature dated before the revocation, impersonating the owner of the key. A recipient of that signature would mistakenly consider this signature valid if the issuing key has been soft revoked. This is a problem.
To counteract this problem, it is reasonable to clearly mark compromised keys as suspect at any point in time. That's what hard revocations do.
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