mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-23 08:02:05 +01:00
ch4: Edit main part of the text
This commit is contained in:
Heiko Schaefer
parent
ea7dc03e46
commit
1f18e9a8ff
2 changed files with 77 additions and 74 deletions
|
|
@ -50,6 +50,7 @@ In OpenPGP version 6, AEAD is used to solve the problem of "malleability": In pa
|
|||
|
||||
Public-key cryptography doesn't require participants to pre-arrange a shared secret.
|
||||
|
||||
(asymmetric_key_pair)=
|
||||
### Asymmetric cryptographic key pairs
|
||||
|
||||
In many places, we'll deal with asymmetric cryptographic key pairs:
|
||||
|
|
|
|||
|
|
@ -1,32 +1,34 @@
|
|||
(certificates_chapter)=
|
||||
# Certificates
|
||||
|
||||
One central (and non-trivial) element of OpenPGP are certificates (also often called "OpenPGP keys"). OpenPGP certificates are relatively complex data structures, so it's good to have a clear mental model of them.
|
||||
One central (and non-trivial) element of OpenPGP are "OpenPGP certificates" (also often called "OpenPGP keys"). OpenPGP certificates are relatively complex data structures, so it's good to have a clear mental model of them.
|
||||
|
||||
## Terminology: The various meanings of "key"
|
||||
|
||||
The concept of "(cryptographic) keys" plays a central role, when looking at OpenPGP certificates. Confusingly, the term can be used to refer to a number of subtly different things.
|
||||
|
||||
### Private vs. public keys
|
||||
|
||||
First, without additional context, the word "key" can refer either to public, or to private key material.
|
||||
First, without additional context, the word "key" can refer either to public, or to private asymmetric key material (or even to symmetric keys, but those don't play a role in OpenPGP certificates).
|
||||
|
||||
### Layers of "keys," in OpenPGP
|
||||
|
||||
Independent of the distinction between private and public keys, in OpenPGP, the term "key" is used to refer to three different layers, all related but distinct:
|
||||
|
||||
1. A (bare) "cryptographic key" (without additional metadata). Those might be the private and/or public parameters that form a key, e.g., in case of an RSA private key, the exponent `d` along with the prime numbers `p` and `q`.
|
||||
2. An OpenPGP *component key*: Either an "OpenPGP primary key", or an "OpenPGP subkey". A component key is one building block of an OpenPGP certificate. It consists of a (bare) cryptographic keypair combined some invariant metadata (e.g. key creation time).
|
||||
3. An "OpenPGP certificate" (or "OpenPGP key"): Consists of a number of component keys plus additional elements, such as identity information. (e.g., OpenPGP "key servers" serve this type of object).
|
||||
1. A (bare) ["cryptographic key"](asymmetric_key_pair) (without additional metadata). Those might be the private and/or public parameters that form a key, e.g., in case of an RSA private key, the exponent `d` along with the prime numbers `p` and `q`.
|
||||
2. An OpenPGP *component key*: Either an "OpenPGP primary key", or an "OpenPGP subkey". A component key is one building block of an OpenPGP certificate. It consists of a cryptographic keypair combined some invariant metadata (e.g. key creation time).
|
||||
3. An "OpenPGP certificate" (or "OpenPGP key"): Consists of a number of component keys, identity information and additional elements.
|
||||
|
||||
In the following section, we'll look at the two OpenPGP-specific layers (2 and 3).
|
||||
|
||||
|
||||
## Structure of OpenPGP certificates
|
||||
|
||||
An OpenPGP certificate (or "OpenPGP key") is a collection of an arbitrary number of elements. These elements are:
|
||||
An OpenPGP certificate (or "OpenPGP key") is a collection of an arbitrary number of elements:
|
||||
|
||||
- component keys,
|
||||
- identity information, and
|
||||
- other metadata.
|
||||
- Component OpenPGP keys,
|
||||
- Identity information,
|
||||
- Other metadata.
|
||||
|
||||
We sometimes collectively refer to component keys and identity information as the "components" of a certificate.
|
||||
|
||||
|
|
@ -43,36 +45,24 @@ OpenPGP certificates are typically long-lived and may be changed (typically by t
|
|||
|
||||
### OpenPGP component keys
|
||||
|
||||
An OpenPGP component key (either the "OpenPGP primary key," or an "OpenPGP subkey") consists mainly of an asymmetric cryptographic keypair:
|
||||
An OpenPGP certificate usually contains multiple component keys.
|
||||
|
||||
```{figure} diag/keypair.png
|
||||
---
|
||||
---
|
||||
A cryptographic keypair
|
||||
```
|
||||
|
||||
Recall that in many contexts, only the public key material is present:
|
||||
|
||||
```{figure} diag/keypair_pub.png
|
||||
---
|
||||
---
|
||||
Only the public part of a cryptographic keypair
|
||||
```
|
||||
|
||||
Besides a cryptographic keypair, an OpenPGP component key contains additional metadata (including a creation timestamp):
|
||||
Each OpenPGP component key is a thin layer of OpenPGP metadata (and framing) added to an [asymmetric cryptographic keypair](asymmetric_key_pair).
|
||||
|
||||
```{figure} diag/primary_key.png
|
||||
---
|
||||
---
|
||||
|
||||
An OpenPGP component key
|
||||
```
|
||||
|
||||
For each OpenPGP component key, an *OpenPGP fingerprint* can be derived from the combination of the public key material and creation timestamp (plus additional algorithm parameters, for [ECDH Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ecd)):
|
||||
In addition to the cryptographic key pair, an OpenPGP component key contains a key creation timestamp.
|
||||
|
||||
Component key representations that include private key material also contain metadata that specifies the password protection scheme for the private key material.
|
||||
|
||||
For each OpenPGP component key, an *OpenPGP fingerprint* can be derived from the combination of the public key material and creation timestamp (plus additional algorithm parameters, in the case of [ECDH Keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ecd)):
|
||||
|
||||
```{figure} diag/fingerprint.png
|
||||
---
|
||||
---
|
||||
Each OpenPGP component key has a fingerprint
|
||||
|
||||
Every OpenPGP component key can be named by a fingerprint
|
||||
```
|
||||
|
||||
The fingerprint of our example component OpenPGP key is `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3` [^keyid].
|
||||
|
|
@ -81,121 +71,133 @@ The fingerprint of our example component OpenPGP key is `AAA1 8CBB 2546 85C5 835
|
|||
E.g., an OpenPGP version 4 certificate with the fingerprint `B3D2 7B09 FBA4 1235 2B41 8972 C8B8 6AC4 2455 4239` might be referred to by the 64 bit Key ID `C8B8 6AC4 2455 4239` or styled as `0xC8B86AC424554239`.
|
||||
Historically, even shorter 32 bit identifiers have sometimes been used, like this: `2455 4239`, or `0x24554239`. You may still see such identifiers in very old documents about PGP. However, 32 bit identifiers have [been unfit for purpose for a long time](https://evil32.com/). At some point, 32 bit identifiers were called "short Key ID", while 64 bit identifiers were called "long Key ID".
|
||||
|
||||
Component keys are used in one of two roles: either as "OpenPGP primary key," or as an "OpenPGP subkey".
|
||||
|
||||
#### Primary key
|
||||
|
||||
The "OpenPGP primary key" has the same structure as all other component keys. But it serves a central role:
|
||||
The "OpenPGP primary key" is a component key that serves a central role in an OpenPGP certificate:
|
||||
|
||||
- Its fingerprint is used as the unique identifier for the full OpenPGP certificate.
|
||||
- In addition, it is used for lifecycle operations, such as adding or invalidating subkeys or identities in a certificate.
|
||||
- It is used for lifecycle operations, such as adding or invalidating subkeys or identities in a certificate.
|
||||
|
||||
```{admonition} Terminology
|
||||
:class: note
|
||||
|
||||
In the RFC, the OpenPGP primary key is also sometimes referred to as "top-level key." Historically, it has sometimes informally been called "master key."
|
||||
In the RFC, the OpenPGP primary key is also sometimes referred to as "top-level key." It has also sometimes informally been called "master key."
|
||||
```
|
||||
|
||||
#### Subkeys
|
||||
|
||||
In addition to the primary key, modern OpenPGP certificates usually contain "subkeys" in addition to the primary key.
|
||||
In addition to the primary key, modern OpenPGP certificates usually contain a number of "subkeys."
|
||||
|
||||
Subkeys have the same structure as the primary key, but play a subtly different role in the certificate. Subkeys are cryptographically linked with the primary key (more on this below).
|
||||
Subkeys have the same structure as the primary key, but they are used in a different role. Subkeys are cryptographically linked with the primary key (more on this below).
|
||||
|
||||
```{figure} diag/with_subkeys.png
|
||||
:name: Certificate with Subkeys
|
||||
:alt: Three component keys. The primary key is shown at the top. It can be used for certification. Below it, linked with arrows, are two more component keys, used as subkeys. They are marked as "for encryption" and "for signing", respectively.
|
||||
:width: 80%
|
||||
:align: center
|
||||
|
||||
OpenPGP certificates can contain any number of subkeys
|
||||
OpenPGP certificates can contain a number of subkeys
|
||||
```
|
||||
|
||||
As before, a component key consists of a cryptographic keypair combined with additional metadata.
|
||||
#### Key Flags: defining which operations a component key can perform
|
||||
|
||||
Each component key (this includes the primary key, and all subkeys) has a marker that specifies which operations the component key can perform.
|
||||
Each component key has a set of ["Key Flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags) that specify which operations that key can perform.
|
||||
|
||||
#### Key Flags: defining what operations a component key can perform
|
||||
The commonly used key flags are:
|
||||
|
||||
Each component key has ["Key Flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags) that specify which types of operation the key can perform.
|
||||
- **C**ertification (issuing third-party certifications)
|
||||
- **S**igning (signing data)
|
||||
- **E**ncryption (encrypting data)
|
||||
- **A**uthentication (commonly used for OpenPGP authentication)
|
||||
|
||||
The commonly used flags are:
|
||||
By convention, only the primary key is allowed to perform "certification" operations. All other operations can be configured on either the primary key or a subkey.
|
||||
|
||||
- **C**ertification
|
||||
- **S**igning
|
||||
- **E**ncryption
|
||||
- **A**uthentication
|
||||
```{admonition} Note
|
||||
:class: note
|
||||
|
||||
Only the primary key can perform "certification" operations. All other operations can be performed by either the primary key or subkeys.
|
||||
It is considered good practice to have separate component keys for each type of operation: to allow only *Certification* operations with the primary key, and to use separate *Signing*, *Encryption* and *Authentication* subkeys [^key-flag-sharing].
|
||||
```
|
||||
|
||||
It is considered good practice to have separate component keys for each type of operation (specifically: to allow only *Certification* operations for the primary key, and to have separate *Signing*, *Encryption* and *Authentication* subkeys).
|
||||
[^key-flag-sharing]: With ECC algorithms, it's actually not possible to share encryption functionality with the signing-based functionalities, e.g.: ed25519 used for signing; cv25519 used for encryption.
|
||||
|
||||
(Aside: with ECC algorithms, it's actually not possible to share encryption functionality with the signing-based functionalities, e.g.: ed25519 used for signing; cv25519 used for encryption.)
|
||||
|
||||
### Identity components
|
||||
|
||||
#### User IDs
|
||||
|
||||
An OpenPGP certificate can contain any number of User IDs. Each user ID associates the certificate with an identity.
|
||||
An OpenPGP certificate can contain any number of [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13). Each User ID associates the certificate with an identity.
|
||||
|
||||
Typically, these identities are composed of a name and an email address.
|
||||
Often, identities in a User ID consist of a string that is composed of a name and an email address.
|
||||
|
||||
```{figure} diag/user_id.png
|
||||
---
|
||||
---
|
||||
|
||||
OpenPGP certificates can contain any number of User IDs
|
||||
```
|
||||
|
||||
#### Primary UserID and its implications
|
||||
#### Primary User ID and its implications
|
||||
|
||||
One User ID in a certificate has the special property of being the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-primary-user-id).
|
||||
|
||||
User IDs are associated with preference settings (such as preferred encryption algorithms, more on this below). The preferences associated with the Primary User ID are used by default.
|
||||
|
||||
|
||||
#### User attributes
|
||||
|
||||
User attributes are similar to User IDs, but less commonly used.
|
||||
[User attributes](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-attribute-packet-tag-1) are similar to User IDs, but less commonly used.
|
||||
|
||||
|
||||
### Linking the components of an OpenPGP certificate together ("bindings")
|
||||
### Linking the components of an OpenPGP certificate
|
||||
|
||||
Internally, an OpenPGP certificate consists of OpenPGP packets. Those packets are individual, independent chunks of data, and are combined by merely stringing them together, one after the other.
|
||||
|
||||
So far we've looked at the components in an OpenPGP certificate, but certificates actually contain another set of elements, which bind the components together, and add metadata to them.
|
||||
|
||||
Internally, an OpenPGP certificate consists of a sequence of OpenPGP packets. These packets are just stringed together, one after the other. When a certificate is stored in a file[^tpk], it's easy to remove some of these packets, or add new ones.
|
||||
|
||||
[^tpk]: When an OpenPGP certificate is stored as a file, it's in a format that is called [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys) in the RFC
|
||||
[^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, as the owner of my certificate, I don't want a third party to add subkeys (or add identity claims) to my certificate, pretending that I put those components there.
|
||||
However, the owner of a certificate doesn't want a third party to add subkeys (or add identity claims) to their certificate, pretending that the certificate owner put those components there.
|
||||
|
||||
To prevent such malicious addition of components, OpenPGP uses cryptographic signatures. These signatures show the cryptographic identity that has linked a component to an OpenPGP certificate (in many cases, the linking is done by the primary key of the certificate in question).
|
||||
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 (the main part of this linking is done by the primary key of the certificate).
|
||||
|
||||
So while anyone can still unilaterally put subkeys and identity claims into a file with my OpenPGP certificate, OpenPGP implementations that read the file are expected to discard components that aren't cryptographically linked to my certificate.
|
||||
So while anyone can still unilaterally store unrelated subkeys and identity claims in an OpenPGP certificate dataset, OpenPGP implementations that read this file should discard components that don't have a valid cryptographic connection with the certificate.
|
||||
|
||||
#### "Binding" subkeys to an OpenPGP 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.)
|
||||
|
||||
#### Binding subkeys to an OpenPGP 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".
|
||||
|
||||
The subkey binding signature also adds metadata.
|
||||
|
||||
```{figure} diag/subkey_binding.png
|
||||
---
|
||||
---
|
||||
|
||||
Linking an OpenPGP subkey to the primary key with a binding signature
|
||||
```
|
||||
|
||||
##### Signature Subpackets
|
||||
|
||||
- (key-) expiration
|
||||
- flags
|
||||
The [Signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-signature-packet-tag-2) that binds the subkey to the primary key has the signature type [SubkeyBinding](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-subkey-binding-signature-si).
|
||||
|
||||
##### Binding signing subkeys
|
||||
|
||||
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.
|
||||
Binding subkeys that have the "signing" key flag is a special case:
|
||||
|
||||
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."
|
||||
|
||||
Otherwise, Alice could "adopt" Bob's signing subkey and convincingly claim that she made signatures that were in fact issued by Bob.
|
||||
|
||||
This additional "Primary Key Binding Signature" is informally called a "back signature" (because the subkey uses the signature to point "back" to the primary key).
|
||||
```{figure} diag/subkey_binding_backsig.png
|
||||
|
||||
Linking an OpenPGP signing subkey to the primary key with a binding signature, and an embedded primary key binding signature
|
||||
```
|
||||
|
||||
This additional "Primary Key Binding" Signature is informally called a "back signature" (because the subkey uses the signature to point "back" to the primary key).
|
||||
|
||||
|
||||
#### Self-certification of identity claims
|
||||
#### Binding identities with certifying self-signatures
|
||||
|
||||
OpenPGP certificates often contain identity markers. Typically, in the form of "User ID"s (however, User Attributes are analogous for the purpose of this section).
|
||||
"User ID" identity components are bound to an OpenPGP certificate by issuing a self-signature ("User Attributes" work analogously).
|
||||
|
||||
For example, above, we saw the User ID `Alice Adams <alice@example.org>` associated with Alice's key `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`.
|
||||
For example, the User ID `Alice Adams <alice@example.org>` may be associated with Alice's certificate `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`.
|
||||
|
||||
Alice can link a User ID to her OpenPGP certificate with a cryptographic signature. To link a User ID, a signature of the type `PositiveCertification` is created. The signature is issued using the primary (secret) key.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue