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

Fix notes on subpackets

Browse source
This commit is contained in:
Paul Schaub 2023-09-29 15:23:31 +02:00 committed by Heiko Schaefer
parent 91261fe9bc
commit 6c88b1631d
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
book/source/06-certifications.md
View file

@ -61,18 +61,18 @@ Typical use-cases for revocations are marking certificates or individual subkeys
## Signature Subpackets ## Signature Subpackets
A cryptographic signature alone is often not expressive enough to fulfil certain use-cases. A cryptographic signature alone is often not expressive enough to serve certain use-cases.
For this reason, the OpenPGP protocol introduced signature subpackets with rfc4880. For this reason, the OpenPGP protocol introduced signature subpackets with rfc4880.
These are well-defined data structures that can be placed as subelements into signature packets, which give additional context and meaning to a signature. These are well-defined data structures that can be placed as subelements into signature packets, which give additional context and meaning to a signature.
Typical examples are the issuer fingerprint subpacket, which contains the fingerprint of the issuer key, or the key flags subpacket which states, what purpose a component key is intended for. Typical examples are the issuer fingerprint subpacket, which contains the fingerprint of the issuer key, or the key flags subpacket which states, what purpose a component key is intended for.
Signature subpackets can reside in two different areas of a signature packet. Signature subpackets can reside in two different areas of a signature packet.
Subpackets in the *hashed area* are incorporated in the digest calculation that is done during signature calculation and are therefore covered by the cryptographic signature. Subpackets in the *hashed area* are incorporated in the digest calculation that is done during signature calculation and are therefore covered by the cryptographic signature.
Hashed subpackets are *authenticated*. In other words; hashed subpackets are *authenticated*.
If a subpacket is placed in the *unhashed area* instead, it is not included in the signature calculation procedure. If a subpacket is placed in the *unhashed area* instead, it is not included in the signature calculation procedure and is therefore not protected against tampering.
The unhashed area can be used to retroactively add, change or remove subpackets from a signature without invalidating it. The unhashed area can be used to retroactively add, change or remove subpackets from a signature without invalidating it.
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. issuer key ID / issuer fingerprint subpackets, 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.
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.