diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 5cd7c62..c075e5c 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -298,11 +298,11 @@ For more on third-party {term}`certifications`, see {ref}`third_p 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. -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. +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. 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 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 @@ -346,7 +346,6 @@ As a general tendency, it is desirable for OpenPGP users to have the most comple However, there are contexts in which it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`cert-mini`. -(append-only)= ### Merging As described above, OpenPGP certificates are effectively [append-only](append-only) data structures. As part of the practical realization of this fact, OpenPGP software needs to *merge* different copies of a certificate.