vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-30 03:22:06 +01:00
Code Issues Projects Releases Packages Wiki Activity

edits

Browse source
This commit is contained in:
Heiko Schaefer 2023-11-07 21:13:34 +01:00
parent b73789d1c8
commit 1335d5568f
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 20 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -73,6 +73,12 @@ Typical use-cases for revocations are marking certificates or individual subkeys
A revocation signature can either be hard or soft. A soft revocation of a certificate invalidates it from the revocation signature's creation time onwards. This means signatures issued before the revocation remain intact. A hard revocation, by contrast, invalidates the certificate retroactively, rendering all issued signatures invalid, regardless of creation time. Soft revocations are typically used whenever a key or User ID is retired or superseded gracefully, while hard revocations can, for example, signal compromise of secret key material. A revocation signature can either be hard or soft. A soft revocation of a certificate invalidates it from the revocation signature's creation time onwards. This means signatures issued before the revocation remain intact. A hard revocation, by contrast, invalidates the certificate retroactively, rendering all issued signatures invalid, regardless of creation time. Soft revocations are typically used whenever a key or User ID is retired or superseded gracefully, while hard revocations can, for example, signal compromise of secret key material.
```{note}
OpenPGP certificates act as append-only data structures, in practice. Elements of a certiciate can not be removed from the copies on key servers and the OpenPGP systems of third parties, once published. Implementations usually merge all available components and signatures.
Revocations are used as a mechanism to mark components or signatures as invalid.
```
## Self-signatures: Linking the components of a certificate ## Self-signatures: Linking the components of a certificate
So far we've looked at the components in an OpenPGP certificate, but certificates actually contain another set of elements, which bind the components together, and add metadata to them. So far we've looked at the components in an OpenPGP certificate, but certificates actually contain another set of elements, which bind the components together, and add metadata to them.
@ -113,9 +119,15 @@ Linking an OpenPGP subkey to the primary key with a binding signature
The [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-packet-tag-2) that binds the subkey to the primary key has the signature type [SubkeyBinding](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si). The [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-packet-tag-2) that binds the subkey to the primary key has the signature type [SubkeyBinding](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si).
In order to specify an expiration time for the subkey, a key expiration time subpacket can be included. Note, that the validity of the subkey is bounded by that of the primary key, meaning an expired primary key causes the subkey to be invalidated, no matter the subkey expiration time. In order to specify an expiration time for the subkey, a key expiration time subpacket can be included.
Note, that a subkey cannot be "older" than the primary key. The value of the subkeys creation date MUST be greater than that of the primary key. ```{note}
The validity of a subkey is bounded by that of the primary key, meaning an expired primary key causes the subkey to be invalidated, no matter the subkey expiration time.
It's legal for a subkey to not have an explicit expiry time. In that case, its expiration date is implicitly the same as the expiration date of the primary key.
A subkey cannot be "older" than the primary key. The value of the subkeys creation date MUST be greater than that of the primary key.
```
### Special case: Binding signing subkeys to a certificate ### Special case: Binding signing subkeys to a certificate
@ -181,7 +193,9 @@ A soft revocation invalidates the target certificate beginning with the revocati
Contrary, a hard revocation cannot be re-validated. Furthermore, a hard-revoked certificate is invalidated retroactively. Contrary, a hard revocation cannot be re-validated. Furthermore, a hard-revoked certificate is invalidated retroactively.
```{note}
A missing revocation reason subpacket is equivalent with a hard revocation reason. A missing revocation reason subpacket is equivalent with a hard revocation reason.
```
(third_party_cert)= (third_party_cert)=
## Third-party certifications: Making statements about other people's certificates and identities ## Third-party certifications: Making statements about other people's certificates and identities
@ -290,12 +304,12 @@ The structure of such a signature is rather minimal:
| Issuer Fingerprint | Hashed | True or false | Strongly Recommended | The primary key is the issuer | | 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 | | Reason for Revocation | Hashed | True | False | Decides over soft / hard revocation |
In `SubkeyRevocation` signatures, the reason subpacket cannot have value `32`, but instead may be from the range of `0-3`. 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. 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.
#### Revoke a Certificate #### Revoke a Certificate
A user might want to revoke their whole certificate, rendering it unusable. A user might want to revoke their entire certificate, rendering it unusable.
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. 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.
The recommended way to revoke a certificate is by issuing a `KeyRevocation` signature (type 0x20). The recommended way to revoke a certificate is by issuing a `KeyRevocation` signature (type 0x20).
@ -307,11 +321,11 @@ The structure of a key revocation signature is similar to that of a `Certificati
| Issuer Fingerprint | Hashed | True or false | Strongly Recommended | The primary key is the issuer | | 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 | | Reason for Revocation | Hashed | True | False | Decides over soft / hard revocation |
For `KeyRevocation` signatures, the same constraints as for `SubkeyRevocation` signatures apply to the reason subpacket. 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).
#### Common Subpackets #### Common Subpackets
There are some subpackets that are expected to be included in any type of signature. There are some subpackets that are expected to be included in all types of signatures.
* **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. * **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.