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

ch8: edits

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-28 13:59:35 +02:00
parent fd0f0fe713
commit a3b143d732
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -235,7 +235,7 @@ This way, separate capabilities can be assigned to different identities.
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. 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. 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. So 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. 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: The structure of a certification revocation is as follows:
@ -310,7 +310,7 @@ There are some subpackets that are expected to be included in any type of signat
* **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.
* **Issuer Fingerprint**: In order 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. * **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.
```{note} ```{note}
The issuer key might be a subkey. The issuer key might be a subkey.
@ -321,9 +321,9 @@ Since the issuer fingerprint subpacket is self-authenticating, it can either be
### Potential subpacket conflicts and duplication ### Potential 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. 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 precendence over the unhashed area. 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. 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 occurence of a conflicting packet in the hashed area. 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.
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 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. 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.