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

remove 'and providing varying levels of security'

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-16 22:08:05 +01:00
parent 0def7f33ae
commit e6c935eec9
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
book/source/06-signatures.md
View file

@ -113,7 +113,7 @@ They are formatted as key-value pairs, where the keys are defined as [subpacket
### Hashed and unhashed signature subpackets ### Hashed and unhashed signature subpackets
Signature subpackets within OpenPGP can reside in one of two distinct areas of a signature packet, each serving a different purpose and providing varying levels of security. Signature subpackets within OpenPGP can reside in one of two distinct areas of a signature packet, each serving a different purpose.
- **Hashed area**: Hashed subpackets are included in the hash digest of the signature and are thus covered by its cryptographic signature. They reliably express the signer's intent. - **Hashed area**: Hashed subpackets are included in the hash digest of the signature and are thus covered by its cryptographic signature. They reliably express the signer's intent.
- **Unhashed area**: Unhashed subpackets, conversely, are not included in the hash digest for the signature. They are thus not protected against tampering and can be used to retroactively add, change, or remove metadata in a signature packet without affecting its validity. They are primarily used for advisory purposes or in scenarios where the integrity of the subpacket content can be self-authenticated. An example is the issuer fingerprint subpacket, which can be validated through successful signature verification using the referenced issuer key. - **Unhashed area**: Unhashed subpackets, conversely, are not included in the hash digest for the signature. They are thus not protected against tampering and can be used to retroactively add, change, or remove metadata in a signature packet without affecting its validity. They are primarily used for advisory purposes or in scenarios where the integrity of the subpacket content can be self-authenticated. An example is the issuer fingerprint subpacket, which can be validated through successful signature verification using the referenced issuer key.