From c27600fb6f3178c3ae9a5cecd6e2531f8e3f8388 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Wed, 25 Oct 2023 21:06:39 +0200 Subject: [PATCH] edits, more restructuring --- book/source/06-certifications.md | 93 ++++++++++++++++---------------- 1 file changed, 48 insertions(+), 45 deletions(-) diff --git a/book/source/06-certifications.md b/book/source/06-certifications.md index 7164ed0..5a66696 100644 --- a/book/source/06-certifications.md +++ b/book/source/06-certifications.md @@ -22,31 +22,58 @@ For the purpose of this document, the term signature will refer to an OpenPGP [s ## Types of signatures in OpenPGP -OpenPGP signatures can be separated into *signatures on components* and *data signatures*. - -In this chapter, we'll discuss signatures that apply to components: That is, to component keys and identity components. See our chapter {ref}`signing_data`, for a discussion of the other type of signatures in OpenPGP. +The OpenPGP standard defines a set of [Signature Types](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types), each identified by a numerical signature type ID. Signature types define the intent of a signature, and how it needs to be interpreted. ```{figure} mermaid/06-terminology.png -Types of signatures in OpenPGP +An overview of signature types in OpenPGP ``` +OpenPGP signatures can be classified as either: + +- *Signatures on components* (that is: signatures that apply to component keys or identity components), or +- *Data signatures*. + +In this chapter, we'll discuss the first class: Signatures that apply to components. For a discussion of the second class, see our chapter {ref}`signing_data`, + +## Different kinds of signatures on components + +There are two types of components that signatures can apply to: + +- Component keys (primary keys or subkeys). +- Identity components (User IDs or User attributes). + +And there are two important scenarios that we will distinguish. Signatures on components can be issued by: + +- The certificate's owner, using the primary key of the certificate (in which case we call them *self-signatures*), or +- A third party (in which case we call them *third-party signatures*). + +The same OpenPGP signature mechanism is used for all of these cases. So at first, we will discuss the general shape of OpenPGP signatures. + +However, there are differences in some details of the signatures for these different cases, which we will also look into. The semantics differ between these types of signatures. We'll discuss all of this in this chapter. + +## Context-specific meaning + +For some signature types, the meaning of a signature depends in part on who issued it: A self-signature has a different meaning from a signature issued by a third party. + +For example: + +- A [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) issued as a self-signature can be used to set preferences and advertise features that apply to the whole certificate, while +- A similar [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) issued by a third party, which carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket, acts as a statement by the issuer that they delegate trust to the signed certificate (WoT). + +Or: + +Self-certifications of types `0x10` - `0x13` can be used to bind a User ID to a certificate, while the same signature types issued by a third party are statements by the signer that they have checked 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 -Signatures on components are separated into *self-signatures* and *third-party certifications*. -A signature made by a key over components of the same certificate is referred to as a *self-signature*. - -```{note} -The **C**ertify Others key flag is not required in order to issue self-certifications. -It is only necessary to issue valid third-party certifications. -``` - 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. -Other examples for self-signatures are binding signatures for subkeys. -In order to add an OpenPGP subkey to a certificate, a subkey binding signature is calculated over the public primary key, followed by the public subkey. +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. If the subkey itself is intended to be used as a **S**igning key, an extra step is required. To prevent an attacker from being able to "adopt" a victims signing subkey and then being able to claim to be the origin of signatures in fact made by victim, subkey binding signatures for signing subkeys need to include an embedded "back signature" (formally known as primary key binding signature) made by the signing key itself. @@ -56,21 +83,10 @@ If Alice is certain that `Bob Baker ` controls the key `0xB0B`, Bob can then add this signature to his certificate. TODO: More WoT. -### Types of signatures on components - -There are two classes of components that signatures can apply to: - -- Component keys (primary keys or subkeys). -- Identity components (User IDs or User attributes). - -And there are two important scenarios that we will distinguish. Signatures on components can be issued by: - -- The certificate's owner (in which case we call them *self-signatures*), or -- A third party (in which case we call them *third-party signatures*). - -The same OpenPGP signature mechanism is used for all of these cases. So at first, we will discuss the general shape of OpenPGP signatures. - -However, there are differences in some of the details of the signatures for these different cases, which we will then look into - as well as the semantics, which differ between these types of signatures. We'll discuss all of this in this chapter. +```{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 @@ -80,20 +96,7 @@ A revocation is used to retract the statement formed by a prior signature. A subkey revocation signature revokes a prior subkey binding signature, while a certification revocation revokes a certification signature. Typical use-cases for revocations are marking certificates or individual subkeys as unusable, or marking User IDs as no longer used. -A revocation signature can either be hard or soft. A soft revocation of a certificate invalidates it from the revocation signature's creation time onwards, meaning signatures that were issued before the revocation remain intact, while a hard revocation invalidates the certificate retroactively, rendering all issued signatures invalid, regardless of creation time. Soft revocations are typically used whenever a key or User ID is retired or superseded gracefully, while hard revocations can for example signal compromise of secret key material. - -## Signature types - -The OpenPGP standard defines a set of [Signature Types](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types), each identified by a numerical signature type ID. - -Signature types define the intent of a signature, and how it needs to be interpreted. However, the meaning of a signature also depends on who issued it: A self-signature has a different meaning from a signature issued by a third party. - -A [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) issued as a self-signature can be used to set preferences and advertise features that apply to the whole certificate. -A third-party [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) carrying a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket on the other hand can be interpreted as a statement by the issuer that they delegate trust to the signed certificate (WoT). - -Self-certifications of types `0x10` - `0x13` can be used to bind a User ID to a certificate, while the same types issued by a third party are statements by the signer that they have checked 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. +A revocation signature can either be hard or soft. A soft revocation of a certificate invalidates it from the revocation signature's creation time onwards. This means signatures issued before the revocation remain intact. A hard revocation, by contrast, invalidates the certificate retroactively, rendering all issued signatures invalid, regardless of creation time. Soft revocations are typically used whenever a key or User ID is retired or superseded gracefully, while hard revocations can, for example, signal compromise of secret key material. ## Signature subpackets @@ -162,9 +165,9 @@ In order to specify an expiration time for the subkey, a key expiration time sub Note, that a subkey cannot be "older" than the primary key. The value of the subkeys creation date MUST be greater than that of the primary key. -#### Binding signing subkeys +### Special case: Binding signing subkeys to a certificate -Binding subkeys with the "signing" key flag is a special case: +Binding subkeys with the "signing" key flag is a special case. For the most part, it works the same as binding other types of subkeys, but there is an additional requirement: When binding a signing subkey to a primary key, it is not sufficient that the "primary key wants to be associated with the subkey." In addition, the subkey must signal that it "wants to be associated with that primary key."