From f04987df80d8b9c8ca493fca2afd24f851594ebf Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Fri, 29 Sep 2023 15:24:04 +0200 Subject: [PATCH] Add section on packet criticality --- book/source/06-certifications.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/book/source/06-certifications.md b/book/source/06-certifications.md index 353a538..750522e 100644 --- a/book/source/06-certifications.md +++ b/book/source/06-certifications.md @@ -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). 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. 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.