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

ch6: rfc links

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-28 13:43:41 +02:00
parent f9ab3ca17b
commit e7350e8f7a
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -71,8 +71,8 @@ Just a cryptographic signature, combined with a signature type identifier, is of
Subpackets are well-defined data structures that can be placed into signature packets as subelements. They give additional context and meaning to a signature. Subpackets encode data in a key-value format. All possible keys are defined in the RFC as [subpacket type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-subpacket-types-r), and the value format (and meaning) are defined in the RFC for each subpacket type ID.
Typical examples are:
- the *issuer fingerprint* subpacket, which contains the fingerprint of the issuer key, or
- the *key flags* subpacket which defines what purpose a component key is used for, in a certificate.
- the [*issuer fingerprint*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#issuer-fingerprint-subpacket) subpacket, which contains the fingerprint of the issuer key, or
- the [*key flags*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) subpacket which defines what purpose a component key is used for, in a certificate.
Signature subpackets can reside in two different areas of a signature packet:
@ -88,7 +88,7 @@ Each signature subpacket has a flag that indicates whether the subpacket is *cri
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.
RFC Sections [5.2.3.11](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-creation-time) - [5.2.3.36](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-intended-recipient-fingerpr) give guidance on which subpackets are usually marked as critical.
## Advanced topics