vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-23 08:02:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

push final edits of Ch8, clarify use of italics

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-25 10:56:24 +01:00
parent 8d4c1748c7
commit 14a95e1907
1 changed files with 40 additions and 40 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

80
book/source/08-signing_components.md
View file

@ -190,13 +190,13 @@ Note: certification signatures [can be made irrevocable](https://www.ietf.org/ar
#### Hard vs soft revocations
Revocation signatures often include a [*reason for revocation*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation) subpacket, with a code specifying why the revocation was issued. This code determines whether the revocation is considered *soft* or *hard*.
Revocation signatures often include a [*Reason for Revocation* subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation), with a code specifying why the revocation was issued. This code determines whether the revocation is considered *soft* or *hard*.
- **Soft revocation**: This is typically used for graceful or planned invalidation of components, such as retiring or updating components. It invalidates the component from the revocation signature's creation time, but earlier uses remain valid. Soft revocations can be reversed with a new self-signature.
- **Hard revocation**: This irrevocably invalidates the component, affecting all past and future uses. It is typically used to signal compromise of secret key material.
```{note}
A revocation signature lacking a *reason for revocation* subpacket is interpreted as a hard revocation.
A revocation signature lacking a *Reason for Revocation* subpacket is interpreted as a hard revocation.
```
(third_party_cert)=
@ -300,7 +300,7 @@ This signature should have the following structure:
#### Change expiration time
To adjust the expiration time of an OpenPGP certificate, issue a new `DirectKey` signature (type `0x1F`) with a modified Key Expiration Time subpacket. The structure of this signature is identical to the one outlined in the previous section on changing algorithm preferences.
To adjust the expiration time of an OpenPGP certificate, issue a new *DirectKey* signature (type `0x1F`) with a modified Key Expiration Time subpacket. The structure of this signature is identical to the one outlined in the previous section on changing algorithm preferences.
Additionally, the expiration date can be altered for individual User IDs (detailed below) or separate subkeys (see {numref}`bind_subkey`).
@ -320,8 +320,7 @@ In addition to these subpackets, self-certifications for User IDs can include ot
#### Remove or revoke a User ID
Since OpenPGP certificates are often distributed by the means of key servers, new signatures on a certificate are often "merged" into existing copies of the certificate locally by the recipient.
This integration process means it is practically impossible to directly remove signatures or User IDs from a certificate, as there is no way to communicate the intention of packet deletion to the recipient.
Since OpenPGP certificates are often distributed by the means of key servers, new signatures on a certificate are often "merged" into existing copies of the certificate locally by the recipient. This integration process means it is practically impossible to directly remove signatures or User IDs from a certificate, as there is no way to communicate the intention of packet deletion to the recipient.
To effectively mark a User ID as invalid, the user can publish a copy of their certificate with a *CertificationRevocation* signature(type `0x30`) attached to the invalidated User ID. This signature signals that the specified User ID is no longer valid or associated with the certificate holder.
@ -333,7 +332,7 @@ The structure of a certification revocation is as follows:
| Issuer Fingerprint | Hashed | True or False | Strongly Recommended | Indicates the primary key as the issuer |
| Reason for Revocation | Hashed | True | False | Determines the nature of the revocation |
For User ID revocations, the `Reason for Revocation` subpacket is crucial. A value of `0` means no specific reason, leading to a hard revocation, while `32` indicates the User ID is no longer valid, resulting in a soft revocation. Omitting the reason subpacket is also equivalent to a hard revocation.
For User ID revocations, the *Reason for Revocation* subpacket is crucial. A value of `0` means no specific reason, leading to a hard revocation, while `32` indicates the User ID is no longer valid, resulting in a soft revocation. Omitting the reason subpacket is also equivalent to a hard revocation.
It is generally advisable to use reason code `32` for revoking User IDs.
@ -358,57 +357,58 @@ In addition to these subpackets, users can specify algorithm preferences for eac
#### Revoke a subkey
Analogous to User IDs, subkeys can be revoked individually.
This is done by issuing a `SubkeyRevocation` signature (type 0x28) using the primary key.
The structure of such a signature is rather minimal:
Subkeys, like User IDs, can be individually revoked in OpenPGP.
This is done by issuing a `SubkeyRevocation` signature (type `0x28`) using the primary key.
| Subpacket | Area | Critical | Mandatory | Notes |
|-----------|------|----------|-----------|-------|
| Signature Creation Time | Hashed | True | True | Current time |
| Issuer Fingerprint | Hashed | True or false | Strongly Recommended | The primary key is the issuer |
| Reason for Revocation | Hashed | True | False | Decides over soft / hard revocation |
The structure of such a signature is straightforward:
In `SubkeyRevocation` signatures, the [reason subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation) cannot have value `32`, but instead may be from the range of `0-3`.
Values `1` (key superseded) and `3` (key retired and no longer used) are soft reasons, while `0` (no reason) and `2` (key compromised) are considered hard.
| Subpacket | Area | Critical | Mandatory | Notes |
|-------------------------|--------|----------------|-------------------|-------------------------------------------------|
| Signature Creation Time | Hashed | True | True | Current time |
| Issuer Fingerprint | Hashed | True or False | Strongly Recommended | The primary key is the issuer |
| Reason for Revocation | Hashed | True | False | Determines soft or hard revocation |
#### Revoke a Certificate
A user might want to revoke their entire certificate, rendering it unusable.
In `SubkeyRevocation` signatures, the [reason for revocation](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation) subpacket is critical. The values `1` (key superseded) and `3` (key retired and no longer used) indicate soft revocations, whereas values `0` (no reason) and `2` (key compromised) indicate hard revocations.
Depending on the circumstances, they might either want to revoke it softly, e.g. in case of migration to a new certificate, or they want to issue a hard revocation, e.g. in case of secret key material compromise. A soft-revoked certificate can be re-validated at a later point in time, by issuing a new certification, while a hard revocation is typically permanent.
Note that a value of `32` is not applicable in these signatures.
The recommended way to revoke a certificate is by issuing a `KeyRevocation` signature (type 0x20).
The structure of a key revocation signature is similar to that of a `CertificationRevocation` signature.
#### Revoke a certificate
| Subpacket | Area | Critical | Mandatory | Notes |
|-----------|------|----------|-----------|-------|
| Signature Creation Time | Hashed | True | True | Current time |
| Issuer Fingerprint | Hashed | True or false | Strongly Recommended | The primary key is the issuer |
| Reason for Revocation | Hashed | True | False | Decides over soft / hard revocation |
Users may find themselves needing to revoke their entire OpenPGP certificate, rendering it unusable. This could be for various reasons, such as migrating to a new certificate or in response to a compromise of the certificate's secret key material.
For `KeyRevocation` signatures, the same constraints as for `SubkeyRevocation` signatures apply to the [reason subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation).
While a soft-revoked certificate can be re-validated at a later time with a new certification, a hard revocation is typically permanent.
#### Common Subpackets
The recommended way to revoke a certificate is by issuing a *KeyRevocation* signature (type `0x20`). Its structure is similar to that of a *CertificationRevocation* signature.
There are some subpackets that are expected to be included in all types of signatures.
| Subpacket | Area | Critical | Mandatory | Notes |
|-------------------------|--------|----------------|-------------------|-------------------------------------------------|
| Signature Creation Time | Hashed | True | True | Current time |
| Issuer Fingerprint | Hashed | True or False | Strongly Recommended | The primary key is the issuer |
| Reason for Revocation | Hashed | True | False | Determines soft or hard revocation |
* **Signature Creation Time**: Every OpenPGP signature MUST contain a Signature Creation Time subpacket (2) containing the timestamp at which the signature was made. This packet MUST be present in the hashed area of the signature and SHOULD be marked as critical.
For *KeyRevocation* signatures, the guidelines regarding the [*Reason for Revocation* subpacket] (https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation) are the same as those for *SubkeyRevocation* signatures.
* **Issuer Fingerprint**: To be able to verify a signature, the verifier needs to know which (sub-)key was used to issue the signature in the first place. Therefore, every OpenPGP v6 signature SHOULD contain an Issuer Fingerprint subpacket (33) containing the 32 byte fingerprint of the particular component key that was used to create the signature.
#### Common subpackets in OpenPGP signatures
In OpenPGP, certain subpackets are universally expected across all types of signatures, serving fundamental roles in the signature's structure and verification:
* **Signature Creation Time**: This is a mandatory subpacket in every OpenPGP signature. It contains the timestamp of when the signature was created. For security and integrity, this subpacket must be located in the hashed area of the signature and is recommended to be marked as critical.
* **Issuer Fingerprint**: Essential for signature verification, this subpacket identifies the key (or subkey) used to create the signature. OpenPGP v6 signatures should include the Issuer Fingerprint subpacket, containing the 32-byte fingerprint of the key.
```{note}
The issuer key might be a subkey.
```
Since the issuer fingerprint subpacket is self-authenticating, it can either be included as a hashed or unhashed subpacket, but the authors of this book recommend to place it in the hashed area of the signature.
This subpacket can be placed in either the hashed or unhashed area due to its self-authenticating nature. However, it is recommended to include it in the signature's hashed area for enhanced security.
### Potential subpacket conflicts and duplication
### Managing subpacket conflicts and duplication
Since the hashed and unhashed areas of a signature are just lists of subpackets, in principle they allow duplicates of the same subpacket, which might lead to conflicts.
Therefore, packets in the hashed area take precedence over the unhashed area.
However, there may still be conflicts between packets in the same area, e.g., two conflicting expiration dates, etc.
The [specification recommends](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) that implementations favor the last occurrence of a conflicting packet in the hashed area (that is, the last entry for that subpacket type in the sequence of subpackets in the hashed area).
In OpenPGP signatures, both the hashed and unhashed areas are composed of lists of subpackets. Inherently, this structure permits the duplication of the same subpacket, which could lead to conflicts. To manage these potential conflicts:
In some cases, duplicate packets with conflicting content even make sense, e.g., if a signature was made by a version 4 issuer key whose key material was migrated from an older OpenPGP version such as v3.
In this case, either the v3 or v4 key could be used to validate the v4 signature, but since the key ID calculation scheme was changed between v3 and v4, these identifiers would differ.
Therefore, the signature could contain two issuer key ID subpackets with conflicting, but correct values.
- **Precedence of hashed area**: Subpackets within the hashed area of a signature take precedence over those in the unhashed area. This hierarchy helps resolve conflicts when the same subpacket appears in both areas.
- **Handling conflicts within the same area**: Conflicts can still arise within the same area, such as when two subpackets have different expiration dates. In such cases, the [OpenPGP specification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) advises that implementations should favor the last occurrence of a conflicting subpacket in the hashed area.
In certain scenarios, having duplicate subpackets with conflicting content is logical and even necessary. For example, consider a signature created by a version 4 issuer key, which was upgraded from an older OpenPGP version (like v3). Since the key ID calculation scheme changed from v3 to v4, the identifiers for the same key would differ between these versions. Therefore, a v4 signature might contain two issuer key ID subpackets, each with different, yet correct values for v3 and v4 keys, respectively. This allows for backward compatibility and ensures the signature can be validated under both key ID calculation schemes.