fix link names

This commit is contained in:
Heiko Schaefer 2023-10-29 23:43:14 +01:00
parent bedae03c42
commit 1dbe95cb1f
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
6 changed files with 10 additions and 8 deletions

View file

@ -3,8 +3,7 @@ SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
SPDX-License-Identifier: CC-BY-SA-4.0
-->
(certifications_chapter)=
(component_signatures_chapter)=
# Signatures on components
In this chapter, we'll consider OpenPGP signatures that apply to components. That is, signatures that apply to:
@ -95,6 +94,7 @@ Note, though, that there are some cases where third parties legitimately add "un
[^flooding]: Storing third-party identity certifications in the target OpenPGP certificate is convenient for consumers: it is easy to find all relevant certifications in one central location. However, when third parties can unilaterally add certifications, this opens an avenue for denial-of-service attacks by flooding. The SKS network of OpenPGP key servers [allowed and experienced this problem](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html).
(bind_subkey)=
### Binding subkeys to a certificate
Linking a subkey to an OpenPGP certificate is done with a ["Subkey Binding Signature"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding). Such a signature signals that the "primary key wants to be associated with the subkey".
@ -178,7 +178,8 @@ Contrary, a hard revocation cannot be re-validated. Furthermore, a hard-revoked
A missing revocation reason subpacket is equivalent with a hard revocation reason.
## Third-party signatures: Making statements about other people's certificates and identities
(third_party_cert)=
## Third-party certifications: Making statements about other people's certificates and identities
```{admonition} TODO
:class: warning
@ -214,7 +215,7 @@ This signature should have the following structure:
The recommended way to change the expiration time of a certificate is by issuing a new `DirectKey` signature (type 0x1F) with an adjusted Key Expiration Time subpacket.
The structure of such a signature is the same as in the section above.
It is also possible to change the expiration date of individual User IDs (see section below) or separate subkeys (see [section X](#add_subkey)).
It is also possible to change the expiration date of individual User IDs (see section below) or separate subkeys (see {numref}`bind_subkey`).
#### Add User ID