mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-30 03:22:06 +01:00
Add section on packet criticality
This commit is contained in:
parent
6c88b1631d
commit
f04987df80
1 changed files with 10 additions and 0 deletions
|
@ -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.
|
||||||
|
|
Loading…
Reference in a new issue