edits

book/source/08-signing_components.md

@@ -11,7 +11,9 @@ In this chapter, we'll look into OpenPGP signatures that apply to components of
 - Component keys (primary keys or subkeys) and
 - Identity components (User IDs or User attributes).
 
-This chapter adds detail to material we discussed in the {ref}`certificates_chapter` chapter. Signatures on components are a crucial mechanism for forming OpenPGP certificates and .
+This chapter adds detail to material we discussed in the {ref}`certificates_chapter` chapter. Signatures on components are a crucial mechanism for forming OpenPGP certificates, as well as for life-cycle management of certificates.
+
+Separately, signatures on components serve as a central building block for OpenPGP's decentralized authentication functionality.
 
 ## Self-signatures: Forming certificates and life-cycle management
 
@@ -19,20 +21,19 @@ This chapter adds detail to material we discussed in the {ref}`certificates_chap
  
 Signatures on components are also a central mechanism for life-cycle management of OpenPGP certificates and their components. This includes defining or changing expiration dates, or issuing revocations, for certificates or their components.
 
+```{note}
+The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is not required in order to issue certifying self-signatures. This key flag is only necessary to issue valid third-party certifications.
+```
+
 ## Third-party certifications: Encoding authentication
 
-Additionally, signatures on components play a crucial role in the authentication of identities. Mechanisms for decentralized authentication are one of OpenPGP's core strengths, we'll look into how they work.
+Mechanisms for decentralized authentication of identities are one of OpenPGP’s core strengths: Signatures on components by third parties can be used for the authentication of identities.
 
-## Self-signatures and third-party signatures
+Using OpenPGP signatures, identity claims can be certified by third parties. Similarly, authentication decisions can be delegated using signatures.
 
-There are two important scenarios to distinguish:
+## Meaning differs between self- and third-party signatures
 
-
-- *Third-party signatures*: Issued by a key that is part of a different certificate.
-
-### Meaning differs between self- and third-party signatures
-
-The meaning of a signature depends in part on who issued it. A self-signature often has a different meaning from a signature issued by a third party.
+The meaning of a signature depends in part on who issued it. A self-signature performs a different function than the same type of signature issued by a third party.
 
 For example:
 
@@ -44,13 +45,11 @@ Or:
 - Certifying self-signatures (type IDs `0x10` - `0x13`) are used to bind a User ID to a certificate, while
 - the same signature type IDs issued by a third party are statements by the signer that they endorse the authenticity of the signed User ID to some degree.
 
-There are further signature types for signatures on data, as well as designated types to bind and revoke subkeys.
-
 ## Signatures on components
 
-A typical use-case for a self-signature is to attach a User ID, such as a name and email address to a certificate.
-This is done by calculating the signature over the User ID and the public primary key.
-The resulting User ID certification (typically type 0x13, potentially type 0x10-0x12) can then be inserted into the certificate, right after the User ID packet.
+A typical use-case for a self-signature is to link a User ID, such as a name and email address to a certificate.
+This is done by calculating a signature over the User ID and the public primary key.
+The resulting certification (typically signature type 0x13, potentially type 0x10-0x12) is then stored as part of the certificate, right after the User ID packet.
 
 Other examples for self-signatures are binding signatures for subkeys. To add an OpenPGP subkey to a certificate, a subkey binding signature is calculated over the public primary key, followed by the public subkey.
 The resulting subkey binding signature (type 0x18) can then be inserted into the certificate right after the subkey.
@@ -62,11 +61,6 @@ If Alice is certain that `Bob Baker <bob@example.com>` controls the key `0xB0B`,
 Bob can then add this signature to his certificate.
 TODO: More WoT.
 
-```{note}
-The **certify others** key flag is not required in order to issue certifying self-signatures.
-This key flag is only necessary to issue valid third-party certifications.
-```
-
 ### Revocations
 
 One important class of self-signatures are revocations.
@@ -85,13 +79,15 @@ Internally, an OpenPGP certificate consists of a sequence of OpenPGP packets. Th
 
 [^tpk]: When stored in a file, OpenPGP certificates are in a format called [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys).
 
-However, the owner of a certificate doesn't want a third party to add subkeys (or add [identity components](identity_components)) to their certificate, pretending that the certificate owner put those components there.
+However, the owner of a certificate doesn't want a third party to add subkeys or [identity components](identity_components) to their certificate, pretending that the certificate owner put those components there.
 
 To prevent malicious addition of components, OpenPGP uses cryptographic signatures. These signatures show that components have been added by the owner of the OpenPGP certificate (these linking signatures are issued by the primary key of the certificate).
 
 So while anyone can still unilaterally store unrelated subkeys and [identity components](identity_components) in an OpenPGP certificate dataset, OpenPGP implementations that read this certificate should discard components that don't have a valid cryptographic connection with the certificate.
 
-(Conversely, it's easy for a third party to leave out packets when passing on an OpenPGP certificate. An attacker can, for example, choose to omit revocation packets. The recipient of such a partial copy has no way to notice the omission, without access to a different source for the certificate that contains the revocation packet.)
+```{note}
+Conversely, it's easy for a third party to leave out packets when passing on an OpenPGP certificate. An attacker can, for example, choose to omit revocation packets. The recipient of such a partial copy has no way to notice the omission, without access to a different source for the certificate that contains the revocation packet.
+```
 
 Note, though, that there are some cases where third parties legitimately add "unbound" packets to certificates (that is: packets that are not signed by the certificate's owner):
 
@@ -262,8 +258,7 @@ It is recommended to issue User ID certifications using a reason code `32` and t
 (binding_subkeys)=
 #### Add a Subkey
 
-For the purpose of key freshness, a user might want to add a new subkey to their certificate.
-
+A user might want to add a new subkey to their certificate, for example to replace an old subkey with one that uses a newer cryptographic algorithm.
 
 The structure is as follows:
 
@@ -331,11 +326,11 @@ Since the issuer fingerprint subpacket is self-authenticating, it can either be
 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.
 Therefore, packets in the hashed area take precedence over the unhashed area.
 However, there may still be conflicts between packets in the same area, e.g., two conflicting expiration dates, etc.
-The [specification recommends](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) that implementations favor the last occurrence of a conflicting packet in the hashed area.
+The [specification recommends](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) that implementations favor the last occurrence of a conflicting packet in the hashed area (that is, the last entry for that subpacket type in the sequence of subpackets in the hashed area).
 
 In some cases, duplicate packets with conflicting content even make sense, e.g., if a signature was made by a version 4 issuer key whose key material was migrated from an older OpenPGP version such as v3.
 In this case, either the v3 or v4 key could be used to validate the v4 signature, but since the key ID calculation scheme was changed between v3 and v4, these identifiers would differ.
-Therefore, the signature could contain two isuer key ID subpackets with conflicting, but correct values.
+Therefore, the signature could contain two issuer key ID subpackets with conflicting, but correct values.
 
 ```{admonition} TODO
 :class: warning