vanitasvitae
/
openpgp-notes
mirror of https://codeberg.org/openpgp/notes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

change introduction and section on certificate validity

This commit is contained in:
Tammi L. Coles 2024-02-08 12:06:44 +01:00
parent 057e72e5d4
commit a23321f3b0
1 changed files with 22 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
book/source/adv/certificates.md
View File

@ -19,67 +19,51 @@ OpenPGP certificates are crucial for a wide range of applications, from secure e
In this chapter, we aim to delve deeper into the advanced concepts surrounding OpenPGP certificates, focusing on their validity, expiration, and the critical role they play in ensuring the security and reliability of cryptographic communications. By exploring these concepts, we aim to provide readers with a comprehensive understanding of how OpenPGP certificates function within the ecosystem, their practical applications, and best practices for managing certificate validity and expiration to maintain a secure cryptographic environment.
## Certificate validity and expiration
## Certificate validity, expiration, and revocation
Maintaining the validity of OpenPGP certificates is essential for the security and reliability of cryptographic communications. Expiration dates play a key role in this process, acting as a built-in check that prompts users to review and renew their certificates periodically.
OpenPGP certificates are integral to establishing and maintaining secure communication channels. These certificates, being composites of various components linked by [signatures](../signing_components), embody the trust and authentication mechanisms underpinning the OpenPGP standard. This section explores the dual aspects of certificate validity: expiration and revocation, and how they govern the lifecycle of a certificate and its individual components.
Certificates are composites of components that are linked together using [signatures](../signing_components).
### Understanding certificate expiration
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.
Certificates and their components within the OpenPGP framework are subject to expiration, a mechanism designed to ensure timely review and renewal of cryptographic credentials. Expiration delineates a clear validity period, beyond which a certificate or its specific components, such as subkeys or identities, are considered invalid.
In this section, we discuss the validity of certificates and their components. This discussion is closely related to [signature validity](/verification), and builds on that concept.
Certificates can "expire," rendering them and their individual components invalid unless renewed. OpenPGP software will refuse to encrypt email using an expired certificate, adhering to the expressed preferences in the certificate's metadata. This refusal acts as a safeguard, prompting certificate owners to update or renew their certificates to maintain operational security.
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:
Expiration dates are set using *Key Expiration Time* subpackets for subkeys, and [*signature expiration time* subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#signature-expiration-subpacket) for identity components. An expired binding signature invalidates the component it is associated with, emphasizing the critical role of timely updates.
- Expiration
- Revocation
### The role of expiration in certificate freshness
### Expiration
The expiration mechanism serves a crucial function beyond merely invalidating old or compromised certificates. It acts as a proactive catalyst for certificate renewal, ensuring that the OpenPGP ecosystem remains vibrant with up-to-date cryptographic keys and identities.
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.
Utilizing expiration dates fulfills two primary objectives: it compels the polling for certificate updates, such as from a keyserver, and it provides a passive mechanism for certificates to "time out." This is particularly vital if a certificate owner loses control over their certificates or is unable to issue a revocation.
The OpenPGP software of a sender will refuse to encrypt email using an expired certificate, or using 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.
By mandating regular updates through expiration, the OpenPGP standard ensures that certificates reflect the current cryptographic stance of their owners, thereby enhancing the overall security and reliability of the network. This mechanism ensures that certificates maintain their relevance and trustworthiness, fostering a culture of active security management and vigilance among users.
The expiration mechanism in OpenPGP is complemented by a mechanism to extend/renew expiration time.
### Introduction to certificate revocation
Using the expiration mechanism is useful for two reasons:
Revocation is a critical security mechanism in the OpenPGP standard, allowing for the invalidation of a certificate or its components. Unlike expiration, which is inherently time-based, revocation is an explicit declaration that a certificate or component should no longer be trusted or used.
- Expiration of a certificate means that it cannot be used anymore. This forces users of that certificate (or their OpenPGP software) to poll for updates for it. For example, from a keyserver.
- 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.
OpenPGP certificates are designed as "append only" data structures, meaning that once a component or signature is added, it cannot simply be removed. Instead, to invalidate a certificate or component, revocation signatures are issued and appended to the certificate. This method ensures that the historical record is preserved, maintaining a full audit trail of actions taken over the certificate's lifecycle.
Component keys use *Key Expiration Time* subpackets for expressing the expiration time. Identity components rely on the [*signature expiration time*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#signature-expiration-subpacket) subpacket of their binding signature. If a binding signature expires, the binding becomes invalid, and the component is considered expired.
### Revocation mechanisms and types
### Revocation
Revocation can apply to individual components of a certificate, such as User IDs and subkeys, allowing specific elements to be marked as invalid without affecting the overall certificate. However, revoking the *primary User ID* or 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`) has a more significant effect, marking the entire certificate and all its components as invalid and unusable.
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.
The OpenPGP standard facilitates various [*Reasons for Revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#reason-for-revocation), each denoting the specific rationale behind the revocation. These reasons allow for nuanced distinctions between "soft" and "hard" revocations, impacting how the revocation affects the certificate's use:
Each component, such as User ID and a subkey, can be revoked without affecting the rest of the certificate.
- *Soft revocations* (e.g., *Key is superseded*, *Key is retired*, *User ID is no longer valid*) suggest that the revoked component may still have valid uses before the revocation time, allowing for historical verification of signatures.
- *Hard revocations* signal a significant trust breach, such as key compromise, and are treated as valid from the moment of the key's creation, effectively invalidating it for all time.
The *primary User ID* is an exception: when it is revoked, the entire certificate is considered invalid.
### Semantics of revocations
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`) also marks the entire certificate, including all of its components, as invalid and unusable.
Revocation semantics play a crucial role in the OpenPGP trust model, particularly in distinguishing between hard and soft revocations. Hard revocations are irreversible and signal that a certificate or component should never be used again, addressing scenarios where a private key is compromised. In contrast, soft revocations allow for the possibility that a component was valid in the past but is no longer appropriate for current use, such as when a subkey is retired in favor of a new one.
### Semantics of Revocations
This distinction is vital for evaluating the validity of components or signatures at a specified reference time. Hard revocations invalidate a component at all points in time, including before the creation of the revocation signature, to prevent misuse by attackers. Soft revocations, however, leave the door open for the component's use before the revocation, acknowledging its past validity[^undo-revocations].
In contrast to expiration, revocation is typically final and not withdrawn[^undo-revocations].
By understanding the mechanisms and semantics of revocation, OpenPGP users and implementers can more effectively manage and interpret the validity and trustworthiness of certificates within the ecosystem.
[^undo-revocations]: While some revocations can be reverted, undoing revocations is an uncommon workflow. Unlike expirations, which are commonly undone by extending the expiration time.
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 and therefore 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 (the new binding signature and its metadata then shadow the revocation and re-connect and re-validate the component).
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 using a soft revocation, and the certificate holder moved to a different subkey, then the signatures in the past, made by the retired key, are still valid.
(append-only)=
## Certificates are effectively append-only data structures