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

correct CertificationRevocation section

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-25 11:09:11 +01:00
parent 8fe5dfcf33
commit 78b2766049
1 changed files with 8 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -322,15 +322,16 @@ In addition to these subpackets, self-certifications for User IDs can include ot
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. 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.
The structure of a certification revocation is as follows: The structure of a *CertificationRevocation* 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 | Determines soft or hard revocation |
| Subpacket | Area | Critical | Mandatory | Notes |
|---------------------|--------|----------------|-------------------|---------------------------------------------|
| Signature Creation Time | Hashed | True | True | Should be the current time |
| 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.