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

Revocation

Browse source
This commit is contained in:
Paul Schaub 2023-10-03 14:41:33 +02:00 committed by Heiko Schaefer
parent 23bd402f4e
commit 7bbc2f2434
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 38 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
book/source/06-certifications.md
View file

@ -113,6 +113,8 @@ A revocation is used to retract the statement formed by a prior signature.
A subkey revocation signature revokes a prior subkey binding signature, while a certification revocation revokes a certification signature. A subkey revocation signature revokes a prior subkey binding signature, while a certification revocation revokes a certification signature.
Typical use-cases for revocations are marking certificates or individual subkeys as unusable, or marking User IDs as no longer used. Typical use-cases for revocations are marking certificates or individual subkeys as unusable, or marking User IDs as no longer used.
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, meaning signatures that were issued before the revocation remain intact, while a hard revocation 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.
## Signature Subpackets ## Signature Subpackets
A cryptographic signature alone is often not expressive enough to serve certain use-cases. A cryptographic signature alone is often not expressive enough to serve certain use-cases.
@ -174,6 +176,42 @@ The signature should have the following structure:
Self-certifications over User IDs can optionally carry the same subpackets as listed in the previous table (key flags, features, algorithm preferences). Self-certifications over User IDs can optionally carry the same subpackets as listed in the previous table (key flags, features, algorithm preferences).
This way, separate capabilities can be assigned to different identities. This way, separate capabilities can be assigned to different identities.
#### Remove / Revoke 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 means, that it is not really possible to remove signatures / User IDs from a certificate, as there is no way to communicate the intention of packet deletion to the recipient.
So in order to 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 holder of the certificate no longer wants to be associated with that User ID.
The structure of a certification revocation is as follows:
| 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 |
For User ID revocations, the value of the reason subpacket can either be `0` (no reason specified) or `32`, signaling that the User ID is no longer valid.
The latter would result in a soft revocation, while a reason code of `0` is considered a hard revocation.
Omitting the reason packet altogether is also equivalent to a hard revocation.
It is recommended to issue User ID certifications using a reason code `32` and to do certificate revocations using a direct-key signature.
#### Revoke a Certificate
A user might want to revoke their whole 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.
The recommended way to revoke a certificate is by issuing a key revocation signature (type 0x20).
The structure of a key revocation signature is similar to that of a `CertificationRevocation` signature.
| 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 |
One difference is, that the reason subpacket 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.
#### 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 any type of signature.