From e7350e8f7ab41e8951732222d7440a514c0faa6c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 28 Oct 2023 13:43:41 +0200 Subject: [PATCH] ch6: rfc links --- book/source/06-signatures.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/source/06-signatures.md b/book/source/06-signatures.md index 078fe2c..bb32d4a 100644 --- a/book/source/06-signatures.md +++ b/book/source/06-signatures.md @@ -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