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

edits, more restructuring

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-25 21:06:39 +02:00
parent 8184304cd8
commit c27600fb6f
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 48 additions and 45 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

93
book/source/06-certifications.md
View file

@ -22,31 +22,58 @@ For the purpose of this document, the term signature will refer to an OpenPGP [s
## Types of signatures in OpenPGP ## Types of signatures in OpenPGP
OpenPGP signatures can be separated into *signatures on components* and *data signatures*. 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.
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.
```{figure} mermaid/06-terminology.png ```{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
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. 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. 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. 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. 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.
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.
The resulting subkey binding signature (type 0x18) can then be inserted into the certificate right after the 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. 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. 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 <bob@example.com>` controls the key `0xB0B`,
Bob can then add this signature to his certificate. Bob can then add this signature to his certificate.
TODO: More WoT. TODO: More WoT.
### Types of signatures on components ```{note}
The **certify others** key flag is not required in order to issue certifying self-signatures.
There are two classes of components that signatures can apply to: This key flag is only necessary to issue valid third-party certifications.
```
- 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.
### Revocations ### 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. 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. 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. 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 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.
## Signature subpackets ## 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. 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." 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."