Add section on packet criticality

This commit is contained in:
Paul Schaub 2023-09-29 15:24:04 +02:00 committed by Heiko Schaefer
parent 6c88b1631d
commit f04987df80
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D

View file

@ -75,6 +75,16 @@ The unhashed area can be used to retroactively add, change or remove subpackets
Due to the fact that the unhashed area doesn't provide any cryptographic guarantees, it is only intended for advisory packets, or packets that self-authenticate (e.g. the issuer fingerprint subpacket, whose "correctness" can be proven by successfully verifying the signature using the referenced issuer key). Due to the fact that the unhashed area doesn't provide any cryptographic guarantees, it is only intended for advisory packets, or packets that self-authenticate (e.g. the issuer fingerprint subpacket, whose "correctness" can be proven by successfully verifying the signature using the referenced issuer key).
In most cases, signature subpackets are simply added into the hashed area. In most cases, signature subpackets are simply added into the hashed area.
### Criticality
Each signature subpacket has a flag that indicates whether or not the subpacket is *critical*.
Since different OpenPGP implementations might support subsets of the standard, it would be fatal, if for example an implementation did not understand the concept of signature expiration.
Such an implementation would potentially accept an already expired signature.
By marking the expiration date subpacket as critical, the user can indicate, that implementations that do not understand this type of subpacket are supposed to reject the signature as invalid.
Sections 5.2.3.11 - 5.2.3.36 give guidance on which subpackets are usually marked as critical.
### Potential 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 precendence 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.