mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-09 11:19:41 +02:00
Merge pull request 'rename link anchors' (#230) from renames into draft
Reviewed-on: https://codeberg.org/openpgp/notes/pulls/230
This commit is contained in:
heiko
commit
30f2f681ef
18 changed files with 89 additions and 89 deletions
|
|
@ -11,7 +11,7 @@ This documentation project seeks to introduce all OpenPGP concepts and functiona
|
|||
|
||||
## What is OpenPGP?
|
||||
|
||||
OpenPGP is an open standard for cryptographic operations. It is a system based on well-understood [cryptographic building blocks](/cryptography). OpenPGP supports the secure delivery of files and messages between a sender and a recipient. It also addresses identities and their verification. OpenPGP is an outgrowth of the ["Pretty Good Privacy (PGP)"](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) encryption program and has many widely used and [interoperable implementations](interop-section).
|
||||
OpenPGP is an open standard for cryptographic operations. It is a system based on well-understood [cryptographic building blocks](/cryptography). OpenPGP supports the secure delivery of files and messages between a sender and a recipient. It also addresses identities and their verification. OpenPGP is an outgrowth of the ["Pretty Good Privacy (PGP)"](https://en.wikipedia.org/wiki/Pretty_Good_Privacy) encryption program and has many widely used and [interoperable implementations](interoperability).
|
||||
|
||||
With OpenPGP, you can:
|
||||
|
||||
|
|
|
|||
|
|
@ -102,11 +102,11 @@ When thinking about edge cases, it's useful to "assume the worst." For example:
|
|||
|
||||
Another way to think about this discussion is that different OpenPGP users may have a different view of any certificate. There is a notional "canonical" version of the certificate, but we cannot assume that every user has exactly this copy. Besides propagation of elements that the certificate holder has linked to a certificate, third-party certifications are by design a distributed mechanism. A third-party certification is issued by a third party, and may or may not be distributed widely by them, or by the certificate holder. Not distributing third-party certifications widely is a workflow that may be entirely appropriate for some use cases[^tpc-privacy].
|
||||
|
||||
[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`metadata-graph`.
|
||||
[^tpc-privacy]: The two parties to a certification (the issuer and the target of the certification) may prefer not to publish their mutual association. Also see {ref}`social-graph-metadata-leak`.
|
||||
|
||||
As a general tendency, it is desirable for OpenPGP users to have the most complete possible view of all certificates that they interact with.
|
||||
|
||||
However, there are contexts in which it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`cert-mini`.
|
||||
However, there are contexts in which it is preferable to only use a subset of the available elements of a certificate. We discuss this in the section {ref}`minimization`.
|
||||
|
||||
(certificate-merging)=
|
||||
## Merging
|
||||
|
|
@ -124,7 +124,7 @@ For information that *is* related to the certificate, but not bound to it by a s
|
|||
- Third-party certifications. These could be valuable information, where a third party attests that the association of an identity to a certificate is valid. On the other hand, they could also be a type of spam.
|
||||
- Subpackets in the unhashed area of a signature packet. Again, these could contain information that is useful to the recipient. However, the data could also be either useless, or even misleading/harmful.
|
||||
|
||||
(cert-mini)=
|
||||
(minimization)=
|
||||
## Certificate minimization
|
||||
|
||||
Certificate minimization is the practice of presenting a partial view of a certificate by filtering out some of its components.
|
||||
|
|
@ -167,7 +167,7 @@ GnuPG offers two explicit methods for certificate minimization, described [in th
|
|||
|
||||
Independently, GnuPG by default [strips some signatures on key import](https://dev.gnupg.org/T4607#127792)[^gpg-default-strip]. However, a number of Linux distributions change this default behavior, and continue to import signatures without minimization by default. e.g. [Debian](https://dev.gnupg.org/T4628#128513) and Arch Linux: stripping third-party certifications on import, by default, is problematic for users who want to leverage authentication based on the [Web of Trust mechanism](wot).
|
||||
|
||||
[^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding](cert-flooding) event.
|
||||
[^gpg-default-strip]: GnuPG's changes in the default handling of third-party certifications on imports were prompted by the 2019 [keyserver flooding](keyserver-flooding) event.
|
||||
|
||||
### Limitations that can result from stripping historical self-signatures
|
||||
|
||||
|
|
@ -267,7 +267,7 @@ Note that regardless of the OpenPGP version, software that relies on 8-byte Key
|
|||
|
||||
The historical 4-byte "short Key IDs" format should not be used anywhere, anymore (finding collisions in a 32-bit keyspace has been [trivial for a long time](https://evil32.com/)).
|
||||
|
||||
(email-lookup)=
|
||||
(certificate-lookup-by-email)=
|
||||
### Looking up certificates by email
|
||||
|
||||
Searching OpenPGP certificates by email is a use case that often arises. For example, when composing an email to a new contact, the sender may want to find the OpenPGP certificate for that contact.
|
||||
|
|
@ -278,9 +278,9 @@ Different mechanisms allow certificate lookup by email, for example:
|
|||
- The [keys.openpgp.org](https://keys.openpgp.org/) "verifying keyserver" (also known as ["hagrid"](https://gitlab.com/keys.openpgp.org/hagrid), the name of the server software it runs)
|
||||
- SKS-style OpenPGP keyservers (today, most of these run the [Hockeypuck](https://github.com/hockeypuck/hockeypuck) software)
|
||||
|
||||
Their properties differ, for more see {ref}`distribution`.
|
||||
Their properties differ, for more see [](certificate-distribution).
|
||||
|
||||
(cert-freshness)=
|
||||
(certificate-freshness)=
|
||||
## Certificate freshness: Triggering updates with an expiration time
|
||||
|
||||
For a certificate holder, one problem is that their communication partners may not regularly poll for updates of their certificate.
|
||||
|
|
@ -291,7 +291,7 @@ Once the expiration time is reached, third parties, or ideally their OpenPGP sof
|
|||
|
||||
After the update, the updated copy of the certificate will usually have a fresh expiration time. The same procedure will repeat once that new expiration time has been reached.
|
||||
|
||||
(metadata-graph)=
|
||||
(social-graph-metadata-leak)=
|
||||
## Metadata leak of Social Graph
|
||||
|
||||
Third-party certifications are signatures over identity components made by other users.
|
||||
|
|
@ -307,7 +307,7 @@ Third-party certifications can be published as part of the target certificate to
|
|||
So, there is some tension between the goals of
|
||||
|
||||
- a decentralized system where every participant can access certification information and perform analysis on it locally,
|
||||
- privacy related goals (also see {ref}`email-lookup`, for a comparison of certificate distribution mechanisms, which also touches on this theme).
|
||||
- privacy related goals (also see {ref}`certificate-lookup-by-email`, for a comparison of certificate distribution mechanisms, which also touches on this theme).
|
||||
|
||||
(unbound-user-ids)=
|
||||
## Adding unbound, local User IDs to a certificate
|
||||
|
|
@ -319,7 +319,7 @@ Some OpenPGP software may add User IDs to a certificate, which are not bound to
|
|||
Sequoia additionally certifies these "local, third party, User IDs" with a local trust anchor to facilitate local authentication decisions.
|
||||
To prevent accidental publication of these local User IDs (e.g. to public keyservers), Sequoia marks these binding signatures as "local" artifacts using [Exportable Certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-exportable-certification) subpackets to mark them as non-exportable.
|
||||
|
||||
(distribution)=
|
||||
(certificate-distribution)=
|
||||
## Certificate distribution mechanisms
|
||||
|
||||
Different mechanisms for discovering certificates, and updating certificate data exist in the OpenPGP space:
|
||||
|
|
@ -332,10 +332,10 @@ Different mechanisms for discovering certificates, and updating certificate data
|
|||
|
||||
One central difference between hockeypuck and hagrid (the software that runs the *keys.openpgp.org* service) is that hockeypuck distributes identity packets and third-party certifications that have indeterminate validity, while hagrid does not.
|
||||
|
||||
(cert-flooding)=
|
||||
(keyserver-flooding)=
|
||||
## Third-party certification flooding
|
||||
|
||||
Traditional OpenPGP keyservers are one mechanism for [collection and distribution](distribution) of certificate information. Their model revolves around receiving certificate information from sources that don't identify themselves to the keyserver network. Traditionally, these keyservers have accepted both components bound to certificates by self-signatures, and third party identity certifications.
|
||||
Traditional OpenPGP keyservers are one mechanism for [collection and distribution](certificate-distribution) of certificate information. Their model revolves around receiving certificate information from sources that don't identify themselves to the keyserver network. Traditionally, these keyservers have accepted both components bound to certificates by self-signatures, and third party identity certifications.
|
||||
|
||||
While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks.
|
||||
|
||||
|
|
@ -361,7 +361,7 @@ To achieve these goals, KOO does not serve identity components at all, unless an
|
|||
|
||||
Currently, third-party certification flooding can be worked around by users or administrators requesting the removal/re-adding of a certificate. [See here](https://github.com/hockeypuck/hockeypuck/wiki/HIP-1:-Regaining-control-over-public-key-identity-with-authenticated-key-management).
|
||||
|
||||
Additional mechanisms [are upcoming](1pc3pc-support).
|
||||
Additional mechanisms [are upcoming](support-for-1pa3pc).
|
||||
|
||||
## First-Party attested third-party certifications in OpenPGP (1pa3pc)
|
||||
|
||||
|
|
@ -371,7 +371,7 @@ This mechanism uses the *attested certifications* signature subpacket (type ID `
|
|||
|
||||
[^ac-draft]: Introducing the *attested certifications* signature subpacket (type ID `37`) was unfortunately not in scope of the chartered topics for the current "crypto-refresh" work of the OpenPGP working group. However, hopefully the working group can handle this feature in future rechartering.
|
||||
|
||||
(1pc3pc-support)=
|
||||
(support-for-1pa3pc)=
|
||||
### Support
|
||||
|
||||
- The *keys.openpgp.org* (KOO) keyserver [supports *1pa3pc*](https://gitlab.com/keys.openpgp.org/hagrid/-/commit/39c0e12ac64588220d36bada6497d8396f5915b3).
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ At its core, an OpenPGP private key subsystem performs operations requiring only
|
|||
|
||||
However, the subsystem also supports operations that require additional access to the metadata of the component key. These operations, supplementary to the core keystore operations, do not involve the private key material.
|
||||
|
||||
When implementing a keystore based on hardware cryptographic devices like [OpenPGP card](card-priv), its design will consist of two layers:
|
||||
When implementing a keystore based on hardware cryptographic devices like [OpenPGP card](openpgp-card), its design will consist of two layers:
|
||||
|
||||
- **core layer**: directly handles private key material, and
|
||||
- **supplementary layer**: performs additional cryptographic operations that don't directly use the private key material, such as [AES key wrap](https://www.rfc-editor.org/rfc/rfc3394.html) for ECDH.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ In such cases, the issuer of that signature chooses the hash algorithm locally,
|
|||
|
||||
In contrast, when a message is created for a specific recipient, the sender can - and should - choose the hash algorithm for the signature packet [based on the recipient's hash algorithm preference](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hash-algorithm-preferences).
|
||||
|
||||
The recipient's hash algorithm preference is defined in metadata of their certificate, see {ref}`algo-pref` for more details.
|
||||
The recipient's hash algorithm preference is defined in metadata of their certificate, see {ref}`preferences-features` for more details.
|
||||
|
||||
In this workflow, the signed hash digest is created with a hash algorithm that follows the recipient's preferences, and its intersection with the sender's capabilities and preferences.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
|
||||
Different {term}`signatures<OpenPGP Signature Packet>` in OpenPGP serve various specific purposes. This section provides practical guidance on creating these {term}`signatures<OpenPGP Signature Packet>`, illustrating each with concrete examples.
|
||||
|
||||
(change-algorithm-preferences)=
|
||||
(recipe-algorithm-preferences)=
|
||||
### Change algorithm preferences
|
||||
|
||||
To modify the preferred {term}`symmetric<Symmetric Cryptography>`, compression, {term}`hash<Hash Function>`, or {term}`AEAD algorithms<Authenticated Encryption With Associated Data>` for a {term}`key<Transferable Secret Key>`, the {term}`key owner<Certificate Holder>` needs to issue a {term}`direct key signature` ({term}`type ID<Signature Type ID>` `0x1F`) on the {term}`primary key<OpenPGP Primary Key>`.
|
||||
|
|
@ -67,7 +67,7 @@ For {term}`User ID` {term}`revocations<Revocation>`, the *{term}`Reason for Revo
|
|||
|
||||
It is generally advisable to use reason code `32` for revoking {term}`User IDs<User ID>`.
|
||||
|
||||
(binding-subkeys)=
|
||||
(recipe-binding-subkeys)=
|
||||
### Add a subkey
|
||||
|
||||
As part of {term}`life-cycle management`, users may need to add a new {term}`subkey<OpenPGP Subkey>` to their {term}`OpenPGP certificate`, often for reasons such as upgrading to a {term}`subkey<OpenPGP Subkey>` with more advanced cryptographic algorithms. The process involves creating a specific {term}`signature<OpenPGP Signature Packet>` structure:
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ Both the binary and the ASCII armored format encode exactly the same information
|
|||
|
||||
One noteworthy mechanism in OpenPGP that uses a specialized variant of ASCII armoring is the [*cleartext signature framework*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#cleartext-signature), which stores an ASCII-armored signature and a cleartext message as a combined text file.
|
||||
|
||||
See our section on the [cleartext signature framework](cleartext-sig) for an example of that format.
|
||||
See our section on the [cleartext signature framework](cleartext-signature) for an example of that format.
|
||||
|
||||
## Advanced topics
|
||||
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ For example, an OpenPGP version 4 {term}`certificate<OpenPGP Certificate>` with
|
|||
Historically, even shorter 32-bit identifiers were used, like this: `2455 4239`, or `0x24554239`. Such identifiers still appear in very old documents about PGP. However, [32-bit identifiers have been long deemed unfit for purpose](https://evil32.com/). At one point, 32-bit identifiers were called "short {term}`Key ID`," while 64-bit identifiers were referred to as "long Key ID."
|
||||
|
||||
```{note}
|
||||
In practice, the {term}`fingerprint<OpenPGP Fingerprint>` of a {term}`component key<OpenPGP Component Key>`, while not theoretically unique, functions effectively as a unique identifier. The use of a [cryptographic hash algorithm](crypto-hash) in generating {term}`fingerprints<OpenPGP Fingerprint>` makes the occurrence of two different {term}`component keys<OpenPGP Component Key>` with the same {term}`fingerprint<OpenPGP Fingerprint>` extremely unlikely[^finger-unique].
|
||||
In practice, the {term}`fingerprint<OpenPGP Fingerprint>` of a {term}`component key<OpenPGP Component Key>`, while not theoretically unique, functions effectively as a unique identifier. The use of a [cryptographic hash algorithm](cryptographic-hash) in generating {term}`fingerprints<OpenPGP Fingerprint>` makes the occurrence of two different {term}`component keys<OpenPGP Component Key>` with the same {term}`fingerprint<OpenPGP Fingerprint>` extremely unlikely[^finger-unique].
|
||||
```
|
||||
|
||||
[^finger-unique]: For both {term}`OpenPGP version 6<RFC>` and version 4, the likelihood of accidental occurrence of duplicate {term}`fingerprints<OpenPGP Fingerprint>` is negligible when {term}`key material` is generated based on an acceptable source of entropy. A separate question is if an attacker can purposely craft a second key with the same {term}`fingerprint<OpenPGP Fingerprint>` as a given pre-existing {term}`component key<OpenPGP Component Key>`. With the current state of the art, this is not possible for OpenPGP version 6 and version 4 keys. However, at the time of this writing, the SHA-1-based {term}`fingerprints<OpenPGP Fingerprint>` of OpenPGP version 4 are considered insufficiently strong at protecting against the generation of pairs of {term}`key material` with the same {term}`fingerprint<OpenPGP Fingerprint>`.
|
||||
|
|
@ -122,7 +122,7 @@ In the {term}`RFC`, the {term}`OpenPGP primary key` is occasionally referred to
|
|||
|
||||
Modern {term}`OpenPGP certificates<OpenPGP Certificate>` typically include several {term}`subkeys<OpenPGP Subkey>` in addition to the {term}`primary key<OpenPGP Primary Key>`, although these {term}`subkeys<OpenPGP Subkey>` are optional.
|
||||
|
||||
While {term}`subkeys<OpenPGP Subkey>` have the same structural attributes as the {term}`primary key<OpenPGP Primary Key>`, they fulfill different roles. {term}`Subkeys<OpenPGP Subkey>` are cryptographically linked with the {term}`primary key<OpenPGP Primary Key>`, a relationship further discussed in {numref}`binding-subkeys`.
|
||||
While {term}`subkeys<OpenPGP Subkey>` have the same structural attributes as the {term}`primary key<OpenPGP Primary Key>`, they fulfill different roles. {term}`Subkeys<OpenPGP Subkey>` are cryptographically linked with the {term}`primary key<OpenPGP Primary Key>`, a relationship further discussed in {numref}`bind-subkey`.
|
||||
|
||||
```{figure} plain_svg/Binding_Subkeys.svg
|
||||
:name: fig-subkeys
|
||||
|
|
@ -136,7 +136,7 @@ While {term}`subkeys<OpenPGP Subkey>` have the same structural attributes as the
|
|||
|
||||
{term}`Identity components<Identity Component>` in an {term}`OpenPGP certificate` are used by the {term}`certificate holder` to state that they are known by a certain identifier (like a name, or an email address).
|
||||
|
||||
(user-ids-in-openpgp-certificates)=
|
||||
(user-ids)=
|
||||
### User IDs in OpenPGP certificates
|
||||
|
||||
{term}`OpenPGP certificates<OpenPGP Certificate>` can contain multiple [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#uid). Each {term}`User ID` associates the {term}`certificate<OpenPGP Certificate>` with an {term}`identity`.
|
||||
|
|
@ -167,7 +167,7 @@ Consider this scenario: A third party is confident about the email-based {term}`
|
|||
|
||||
Within a {term}`certificate<OpenPGP Certificate>`, a specific {term}`User ID` is designated as the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id).
|
||||
|
||||
Each {term}`User ID` carries associated preference settings, such as preferred encryption algorithms, which is detailed in {numref}`zooming-in-user-id`). When a {term}`certificate<OpenPGP Certificate>` is used in the context of a specific {term}`identity`, then the preferences associated with that {term}`identity component` are used. When a {term}`certificate<OpenPGP Certificate>` is used without reference to a specific {term}`identity`, the preferences associated with the {term}`direct key signature`, or the {term}`primary User ID` take precedence by default.
|
||||
Each {term}`User ID` carries associated preference settings, such as preferred encryption algorithms, which is detailed in {numref}`zoom-user-id`). When a {term}`certificate<OpenPGP Certificate>` is used in the context of a specific {term}`identity`, then the preferences associated with that {term}`identity component` are used. When a {term}`certificate<OpenPGP Certificate>` is used without reference to a specific {term}`identity`, the preferences associated with the {term}`direct key signature`, or the {term}`primary User ID` take precedence by default.
|
||||
|
||||
The {term}`primary User ID` was historically the main store for preferences that apply to the {term}`certificate<OpenPGP Certificate>` as a whole. For more on this, see {ref}`primary-metadata`.
|
||||
|
||||
|
|
@ -198,9 +198,9 @@ Key attributes, such as {term}`capabilities<Capability>` (like *signing* or *enc
|
|||
|
||||
- **{term}`Primary key<OpenPGP Primary Key>` {term}`metadata`** is defined either through a {term}`direct key signature` on the {term}`primary key<OpenPGP Primary Key>` (preferred in OpenPGP version 6), or by associating the {term}`metadata` with the [Primary User ID](primary-user-id).
|
||||
|
||||
- **{term}`Subkey<OpenPGP Subkey>` {term}`metadata`** is defined within the [subkey binding signature](binding-subkeys) that links the {term}`subkey<OpenPGP Subkey>` to the {term}`certificate<OpenPGP Certificate>`.
|
||||
- **{term}`Subkey<OpenPGP Subkey>` {term}`metadata`** is defined within the [subkey binding signature](recipe-binding-subkeys) that links the {term}`subkey<OpenPGP Subkey>` to the {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
- **{term}`Identity component` {term}`metadata`** is associated via the [certifying self-signature](bind-ident) that links the {term}`identity` (usually in the form of a {term}`User ID`) to the {term}`certificate<OpenPGP Certificate>`.
|
||||
- **{term}`Identity component` {term}`metadata`** is associated via the [certifying self-signature](bind-identity) that links the {term}`identity` (usually in the form of a {term}`User ID`) to the {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
It is crucial to note that the {term}`components<Component>` of an {term}`OpenPGP certificate` remain static after their creation. The use of {term}`signatures<OpenPGP Signature Packet>` to store {term}`metadata` allows for subsequent modifications without altering the original {term}`component<Component>`. For instance, a {term}`certificate holder` can update the {term}`expiration time` of a {term}`component` by issuing a new, superseding {term}`signature<OpenPGP Signature Packet>`.
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ It is crucial to note that the {term}`components<Component>` of an {term}`OpenPG
|
|||
{term}`Metadata` can be associated with the {term}`primary key<OpenPGP Primary Key>` using a *{term}`direct key signature`*.
|
||||
```
|
||||
|
||||
(capabilities-key-flags)=
|
||||
(key-flags)=
|
||||
### Defining operational capabilities of component keys with key flags
|
||||
|
||||
Each {term}`component key` has a set of ["key flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#key-flags) that delineate the operations a key can perform.
|
||||
|
|
@ -233,7 +233,7 @@ Notably, in many algorithms, encryption and signing-related functionalities (i.e
|
|||
|
||||
[^key-flag-sharing]: With ECC algorithms, it's impossible to combine {term}`encryption<Encryption Key Flag>` functions with those intended for {term}`signing<Signing Key Flag>`. For example, ed25519 is specifically used for {term}`signing<Signing Key Flag>`; cv25519 is designated for {term}`encryption<Encryption Key Flag>`.
|
||||
|
||||
(algo-pref)=
|
||||
(preferences-features)=
|
||||
### Algorithm preferences and feature signaling
|
||||
|
||||
OpenPGP incorporates significant ["cryptographic agility"](https://en.wikipedia.org/wiki/Cryptographic_agility). It doesn't rely on a single fixed set of algorithms. Instead, it defines a suite of cryptographic primitives from which users (or their applications) can choose.
|
||||
|
|
@ -291,4 +291,4 @@ Take, for instance, a scenario where Bob's OpenPGP software issues a {term}`cert
|
|||
|
||||
This process assumes that Bob knows the person known as `Alice Adams` and is confident that `alice@example.org` is indeed Alice's email address. Bob also verifies that the {term}`certificate<OpenPGP Certificate>` his OpenPGP software associates with Alice matches the one Alice uses. In essence, both users must have a {term}`certificate<OpenPGP Certificate>` for Alice with an identical {term}`fingerprint<OpenPGP Fingerprint>`. In OpenPGP version 6, manual {term}`fingerprint<OpenPGP Fingerprint>` comparison by end-users is discouraged, with a replacement {term}`verification` mechanism still under development. The {term}`verification` process must occur over a sufficiently secure channel, such as an end-to-end encrypted video call or a face-to-face meeting.
|
||||
|
||||
For more on third-party {term}`certifications<Certification>`, see {ref}`third-party-cert`.
|
||||
For more on third-party {term}`certifications<Certification>`, see {ref}`third-party-certifications`.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
|
||||
# Cryptographic concepts and terms
|
||||
|
||||
(crypto-hash)=
|
||||
(cryptographic-hash)=
|
||||
## Cryptographic hash functions
|
||||
|
||||
[Cryptographic hash functions](https://en.wikipedia.org/wiki/Cryptographic_hash_function) take data strings of any length (like a text message or file) and output a fixed-size code, a "hash digest," which is often abbreviated as either "digest" or "hash." A hash digest is also sometimes called a "(cryptographic) checksum." A hash digest acts like a unique identifier for the original data.
|
||||
|
|
@ -15,7 +15,7 @@ Cryptographic hash functions have two important properties:
|
|||
- [**Pre-image resistance**](https://en.wikipedia.org/wiki/Preimage_attack): Given a hash digest, it should be very difficult to determine any data that matches this hash digest (including, but not limited to, the original data the hash represents). This property embodies the concept of a [one-way function](https://en.wikipedia.org/wiki/One-way_function) – a calculation that is easy to perform, but very hard to reverse.
|
||||
- [**Collision resistance**](https://en.wikipedia.org/wiki/Collision_resistance): It should be very difficult to find two distinct pieces of data that map to the same hash digest.
|
||||
|
||||
(message-authentication-codes)=
|
||||
(message-authentication-code)=
|
||||
## Message authentication codes
|
||||
|
||||
A [message authentication code](https://en.wikipedia.org/wiki/Message_authentication_code) (MAC), also known as an {term}`authentication tag`, is a small piece of information used to verify the integrity and authenticity of a message.
|
||||
|
|
@ -31,7 +31,7 @@ One application of KDFs is to generate symmetric key material from a password by
|
|||
|
||||
A notable KDF for the OpenPGP specification is the [HKDF](https://en.wikipedia.org/wiki/HKDF), which is a key derivation function based on the HMAC.
|
||||
|
||||
For detailed information on KDFs and their role in the OpenPGP protocol, see the [encrypted secrets](encrypted-secrets) chapter and the [SEIPDv2](SEIPDv2) section of the encryption chapter.
|
||||
For detailed information on KDFs and their role in the OpenPGP protocol, see the [encrypted secrets](protected-private-keys) chapter and the [SEIPDv2](seipd-v2) section of the encryption chapter.
|
||||
|
||||
(symmetric-key-cryptography)=
|
||||
## Symmetric-key cryptography
|
||||
|
|
@ -81,7 +81,7 @@ By addressing the malleability problem, AEAD also counters a variation of the EF
|
|||
|
||||
[^efail]: A variation of the [EFAIL](https://en.wikipedia.org/wiki/EFAIL) attack can be prevented by both the MDC and AEAD mechanisms. Also see ["No, PGP is not broken, not even with the Efail vulnerabilities,"](https://proton.me/blog/pgp-vulnerability-efail) especially the section "Malleability Gadget Exfiltration Channel Attack."
|
||||
|
||||
(public-key-asymmetric-cryptography)=
|
||||
(public-key-cryptography)=
|
||||
## Public-key (asymmetric) cryptography
|
||||
|
||||
[Public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) uses asymmetric pairs of related keys. Each pair consists of a public key and a private key. These systems support encryption, decryption, and digital signature operations.
|
||||
|
|
@ -137,7 +137,7 @@ In OpenPGP, digital signatures have diverse applications, extending beyond mere
|
|||
(hybrid-cryptosystems)=
|
||||
## Hybrid cryptosystems
|
||||
|
||||
[Hybrid cryptosystems](https://en.wikipedia.org/wiki/Hybrid_cryptosystem) combine the use of {term}`symmetric<Symmetric Cryptography>` and {term}`asymmetric (public-key)<Asymmetric Cryptography>` cryptography to capitalize on the strengths of each, namely {term}`symmetric cryptography`'s speed and efficiency and {term}`public-key cryptography<Asymmetric Cryptography>`'s mechanism for secure key exchange.
|
||||
[Hybrid cryptosystems](https://en.wikipedia.org/wiki/Hybrid_cryptosystem) combine the use of {term}`symmetric<Symmetric Cryptography>` and {term}`asymmetric (zoom-public-key)<Asymmetric Cryptography>` cryptography to capitalize on the strengths of each, namely {term}`symmetric cryptography`'s speed and efficiency and {term}`public-key cryptography<Asymmetric Cryptography>`'s mechanism for secure key exchange.
|
||||
|
||||
### Usage and terminology in OpenPGP
|
||||
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ When communicating with a mix of recipients, some of whose OpenPGP software only
|
|||
With SEIPDv1, the session key is directly used as message key to encrypt the payload
|
||||
```
|
||||
|
||||
(seipdv2)=
|
||||
(seipd-v2)=
|
||||
### v2 SEIPD, based on AEAD
|
||||
|
||||
The [version 2 SEIPD](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#version-two-seipd) mechanism was introduced in OpenPGP version 6. Consequently, it can only be used for encryption when all recipients explicitly announce support for it using a *Feature* signature subpacket.
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ AEAD Algorithm
|
|||
Algorithm Preferences
|
||||
The preferences for {term}`hash algorithms<Hash Function>`, {term}`compression algorithms<Data Compression>`, {term}`symmetric algorithms<Symmetric Cryptography>` and {term}`AEAD algorithms<Authenticated Encryption With Associated Data>` are set using {term}`direct key signatures<Direct Key Signature>` or {term}`primary User ID` {term}`binding signatures<Binding Signature>`.
|
||||
|
||||
See [](change-algorithm-preferences).
|
||||
See [](recipe-algorithm-preferences).
|
||||
|
||||
Asymmetric Cryptography
|
||||
Asymmetric cryptography is used in OpenPGP. For a more detailed discussion see [](public-key-asymmetric-cryptography).
|
||||
Asymmetric cryptography is used in OpenPGP. For a more detailed discussion see [](public-key-cryptography).
|
||||
|
||||
Authenticated Encryption With Associated Data
|
||||
Short AEAD, refers to an encryption scheme that ensures confidentiality of a message. Additionally, additional data, which is not confidential, may be associated with the message.
|
||||
|
|
@ -32,7 +32,7 @@ Authentication
|
|||
The term "authentication" here is semantically different from the one used in {term}`Authentication Key Flag`.
|
||||
|
||||
Authentication Key Flag
|
||||
A {term}`Key Flag`, which indicates that a {term}`Component Key` can be used to confirm control over {term}`private key material` against a remote system. The term "authentication" here is semantically different from {term}`Authentication`. See [](capabilities-key-flags).
|
||||
A {term}`Key Flag`, which indicates that a {term}`Component Key` can be used to confirm control over {term}`private key material` against a remote system. The term "authentication" here is semantically different from {term}`Authentication`. See [](key-flags).
|
||||
|
||||
Authentication Tag
|
||||
See {term}`Message Authentication Code`.
|
||||
|
|
@ -49,18 +49,18 @@ Binary Signature
|
|||
Binding
|
||||
The process of creating a {term}`Binding Signature` for a {term}`Component`, or the resulting {term}`Binding Signature`.
|
||||
|
||||
See {ref}`binding-sigs` for more.
|
||||
See {ref}`binding-signatures` for more.
|
||||
|
||||
Binding Signature
|
||||
A {term}`self-signature` on a {term}`component` which associates that {term}`component` to the issuing {term}`component key` in a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
See {ref}`binding-sigs` for more.
|
||||
See {ref}`binding-signatures` for more.
|
||||
|
||||
CA
|
||||
See {term}`Certification Authority`.
|
||||
|
||||
Capability
|
||||
The operations an {term}`OpenPGP Component Key` can perform. See [](capabilities-key-flags).
|
||||
The operations an {term}`OpenPGP Component Key` can perform. See [](key-flags).
|
||||
|
||||
Certificate
|
||||
See {term}`OpenPGP Certificate`
|
||||
|
|
@ -74,13 +74,13 @@ Certificate Holder
|
|||
Certification
|
||||
A certification, in OpenPGP, is a signature that makes a statement about an {term}`identity` in a {term}`certificate<OpenPGP Certificate>`, or an entire {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
Most commonly, the term is applied to "[third-party certifications](third-party-cert)," in which an external actor indicates that they have {term}`validated<Validation>` the link between an {term}`identity` and a {term}`certificate<OpenPGP Certificate>`. However, the term is also used for [self-signatures that bind identity components](bind-ident) to a {term}`certificate<OpenPGP Certificate>`.
|
||||
Most commonly, the term is applied to "[third-party certifications](third-party-certifications)," in which an external actor indicates that they have {term}`validated<Validation>` the link between an {term}`identity` and a {term}`certificate<OpenPGP Certificate>`. However, the term is also used for [self-signatures that bind identity components](bind-identity) to a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
Certification Authority
|
||||
Also known as [Certificate authority](https://en.wikipedia.org/wiki/Certificate_authority), this is an entity that handles digital certificates, especially by signing or issuing them.
|
||||
|
||||
Certification Key Flag
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for issuing third-party {term}`certifications<Certification>`. See [](capabilities-key-flags).
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for issuing third-party {term}`certifications<Certification>`. See [](key-flags).
|
||||
|
||||
Certification Revocation Signature Packet
|
||||
An {term}`OpenPGP Signature Packet` to {term}`revoke<Revocation>` an earlier {term}`self-certification` of a {term}`User ID`.
|
||||
|
|
@ -100,7 +100,7 @@ Cipher Type Byte
|
|||
This historical term was defined in [RFC 1991](https://datatracker.ietf.org/doc/html/rfc1991#section-4.1) and was subsequently superseded by {term}`Packet Tag` in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-4.2), which is in turn superseded by {term}`Packet Type ID` in the new [RFC](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-headers).
|
||||
|
||||
Cleartext Signature
|
||||
A {term}`Data Signature` which exists in a combined text format, encapsulating the (readable) text input it was created for. See [](cleartext-sig).
|
||||
A {term}`Data Signature` which exists in a combined text format, encapsulating the (readable) text input it was created for. See [](cleartext-signature).
|
||||
|
||||
Cleartext Signature Framework
|
||||
A framework for creating {term}`cleartext signatures<Cleartext Signature>`.
|
||||
|
|
@ -151,7 +151,7 @@ Delegation
|
|||
This kind of delegation involves {term}`certifications<Certification>` that include the {term}`trust signature` subpacket.
|
||||
|
||||
Detached Signature
|
||||
A {term}`Data Signature` which exists as a separate file to the file it was created for. See [](forms-of-openpgp-data-signatures).
|
||||
A {term}`Data Signature` which exists as a separate file to the file it was created for. See [](forms-of-data-signatures).
|
||||
|
||||
Direct Key Signature
|
||||
A {term}`Signature` that sets preferences and advertises {term}`features<Features Subpacket>` applicable to an entire {term}`Certificate`. See [](direct-key-signature).
|
||||
|
|
@ -162,7 +162,7 @@ Embedded Signature Subpacket
|
|||
See [RFC 5.2.3.34](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-embedded-signature)
|
||||
|
||||
Encryption Key Flag
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for encrypting data. See [](capabilities-key-flags).
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for encrypting data. See [](key-flags).
|
||||
|
||||
Expiration
|
||||
A mechanism by which a {term}`Component` is invalidated due to the {term}`Expiration Time` of its {term}`binding signature` being older than the {term}`Reference Time` by which it is validated.
|
||||
|
|
@ -173,7 +173,7 @@ Expiration Time
|
|||
Features Subpacket
|
||||
A {term}`OpenPGP Signature Subpacket`, which denotes advanced OpenPGP features an {term}`implementation<OpenPGP Implementation>` supports.
|
||||
|
||||
For an in-depth view on these {term}`subpackets<OpenPGP Signature Subpacket>` see [](zooming-in-dks).
|
||||
For an in-depth view on these {term}`subpackets<OpenPGP Signature Subpacket>` see [](zoom-dks).
|
||||
|
||||
See [RFC 5.2.3.32](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-features)
|
||||
|
||||
|
|
@ -191,13 +191,13 @@ Hash Algorithm
|
|||
See {term}`Hash Function`.
|
||||
|
||||
Hash Digest
|
||||
Output of a cryptographic hash function for a string of data of any length. See [](crypto-hash).
|
||||
Output of a cryptographic hash function for a string of data of any length. See [](cryptographic-hash).
|
||||
|
||||
Hash Function
|
||||
A function used to map data of arbitrary size to fixed-size values (see {term}`Hash Digest`).
|
||||
|
||||
Hashed Area
|
||||
An area in an {term}`OpenPGP Signature Packet` containing {term}`OpenPGP Signature Subpacket`s, that is covered by the {term}`Hash Digest` a {term}`Cryptographic Signature` is created for. See [](hashed-and-unhashed-signature-subpackets).
|
||||
An area in an {term}`OpenPGP Signature Packet` containing {term}`OpenPGP Signature Subpacket`s, that is covered by the {term}`Hash Digest` a {term}`Cryptographic Signature` is created for. See [](subpacket-areas).
|
||||
|
||||
Hashed Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket` residing in the {term}`Hashed Area` of an {term}`OpenPGP Signature Packet`.
|
||||
|
|
@ -224,7 +224,7 @@ Initial Introducer
|
|||
An {term}`OpenPGP Certificate` explicitly {term}`delegated<Delegation>` to from a {term}`Trust Anchor`.
|
||||
|
||||
Inline Signature
|
||||
A {term}`Data Signature` which exists encapsulated alongside the data it was created for in an OpenPGP container. See [](forms-of-openpgp-data-signatures).
|
||||
A {term}`Data Signature` which exists encapsulated alongside the data it was created for in an OpenPGP container. See [](forms-of-data-signatures).
|
||||
|
||||
Issuer
|
||||
An entity, that created an {term}`OpenPGP Signature Packet` using an {term}`Transferable Secret Key`.
|
||||
|
|
@ -295,7 +295,7 @@ Master Key
|
|||
See {term}`OpenPGP Primary Key`.
|
||||
|
||||
Message Authentication Code
|
||||
A piece of information used for integrity and {term}`authenticity<Authentication>` verification of a message. See [](message-authentication-codes).
|
||||
A piece of information used for integrity and {term}`authenticity<Authentication>` verification of a message. See [](message-authentication-code).
|
||||
|
||||
Meta-Introducer
|
||||
An {term}`OpenPGP Certificate` with a {term}`Trust Depth` greater than one.
|
||||
|
|
@ -383,7 +383,7 @@ Packet Type ID
|
|||
Positive Certification
|
||||
An {term}`OpenPGP Signature Type` with the {term}`Signature Type ID` `0x13`, which is used in {term}`binding signatures<Binding Signature>` for {term}`User IDs<User ID>`. This {term}`OpenPGP Signature Type` implies that the {term}`issuer` has done substantial {term}`verification` of the {term}`Identity Claim`.
|
||||
|
||||
See [](bind-ident).
|
||||
See [](bind-identity).
|
||||
|
||||
Preferred Compression Algorithms Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred {term}`compression algorithms<Data Compression>` for an {term}`OpenPGP Signature Packet`. This defines which {term}`algorithms<Data Compression>` the {term}`key holder<Certificate Holder>` prefers to use.
|
||||
|
|
@ -418,7 +418,7 @@ Primary Key
|
|||
Primary Key Binding Signature
|
||||
A {term}`Binding Signature`, which is created by a {term}`OpenPGP Signing Subkey` on the {term}`OpenPGP Primary Key` of an {term}`OpenPGP Certificate` and stored in an {term}`Embedded Signature Subpacket` in the {term}`Binding Signature` for the {term}`OpenPGP Signing Subkey`.
|
||||
|
||||
This special case is explained in more detail in [](bind-subkey-sign).
|
||||
This special case is explained in more detail in [](bind-signing-subkey).
|
||||
|
||||
Primary User ID
|
||||
A {term}`User ID` which carries the default preferences for {term}`identity components<Identity Component>` without preferences.
|
||||
|
|
@ -435,7 +435,7 @@ Primary User ID Binding Signature
|
|||
|
||||
This {term}`Binding Signature` may carry {term}`metadata` specific to the {term}`User ID` at hand as well as some applicable to the entire {term}`OpenPGP Certificate`.
|
||||
|
||||
See [](self-signature-binding-to-primary-user-id).
|
||||
See [](primary-user-id-binding).
|
||||
|
||||
Private Key
|
||||
See {term}`Transferable Secret Key`.
|
||||
|
|
@ -447,7 +447,7 @@ Public Key
|
|||
See {term}`OpenPGP Public Key`.
|
||||
|
||||
Public Key Algorithm
|
||||
An {term}`asymmetric cryptographic<Asymmetric Cryptography>` algorithm. See [](public-key-asymmetric-cryptography).
|
||||
An {term}`asymmetric cryptographic<Asymmetric Cryptography>` algorithm. See [](public-key-cryptography).
|
||||
|
||||
Public Key Cryptography
|
||||
See {term}`Asymmetric Cryptography`.
|
||||
|
|
@ -563,7 +563,7 @@ Signing-capable
|
|||
See {term}`Signing Key Flag`.
|
||||
|
||||
Signing Key Flag
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for signing data. See [](capabilities-key-flags).
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for signing data. See [](key-flags).
|
||||
|
||||
Signing Subkey
|
||||
See {term}`OpenPGP Signing Subkey`.
|
||||
|
|
@ -621,7 +621,7 @@ Trust Amount
|
|||
A numerical value between `0` and `255`, stored in {term}`trust signatures<Trust Signature>` used for indicating the degree of reliance on the {term}`delegation`.
|
||||
Values less than `120` indicate partial trust, values equal to or greater than `120` indicate complete trust.
|
||||
|
||||
See [](trust-amounts).
|
||||
See [](trust-amount).
|
||||
See [RFC 5.2.3.21](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature)
|
||||
|
||||
Trust Anchor
|
||||
|
|
@ -630,7 +630,7 @@ Trust Anchor
|
|||
Trust Depth
|
||||
This numerical value is part of a {term}`Trust Signature` and describes the extent of trustworthiness of a {term}`Certification`, that the {term}`signer` assigns to it.
|
||||
|
||||
See [](trust-depth-level).
|
||||
See [](trust-level).
|
||||
|
||||
Trust Level
|
||||
See {term}`Trust Depth`.
|
||||
|
|
@ -661,7 +661,7 @@ Type ID
|
|||
See {term}`Signature Type ID`.
|
||||
|
||||
Unhashed Area
|
||||
An area in a {term}`Signature Packet` containing {term}`Signature Subpacket`s, that is *not* covered by the {term}`Hash Digest` a {term}`Cryptographic Signature` is created for. See [](hashed-and-unhashed-signature-subpackets).
|
||||
An area in a {term}`Signature Packet` containing {term}`Signature Subpacket`s, that is *not* covered by the {term}`Hash Digest` a {term}`Cryptographic Signature` is created for. See [](subpacket-areas).
|
||||
|
||||
Unhashed Subpacket
|
||||
A {term}`Signature Subpacket` residing in the {term}`Unhashed Area` of a {term}`Signature Packet`.
|
||||
|
|
@ -670,7 +670,7 @@ User Attribute
|
|||
An {term}`Identity Component`, which may hold a single JPEG image. See [](user-attributes).
|
||||
|
||||
User ID
|
||||
An {term}`Identity Component`, which describes an {term}`Identity` of a {term}`Certificate Holder`. See [](user-ids-in-openpgp-certificates).
|
||||
An {term}`Identity Component`, which describes an {term}`Identity` of a {term}`Certificate Holder`. See [](user-ids).
|
||||
|
||||
User ID Binding Signature
|
||||
A {term}`Binding Signature`, which is created by an {term}`OpenPGP Primary Key` to bind a {term}`User ID` to an {term}`OpenPGP Certificate`.
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Today, multiple implementations of OpenPGP play important roles:
|
|||
- Proton Mail, which provides email encryption services for a large number of users, uses and maintains [OpenPGP.js](https://openpgpjs.org/) as well as [GopenPGP](https://gopenpgp.org/), an OpenPGP wrapper library written in golang.
|
||||
- The RPM Package Manager software includes an OpenPGP backend based on [Sequoia PGP](https://sequoia-pgp.org/), a modern OpenPGP implementation written in Rust. The Fedora Linux operating system [uses Sequoia PGP in rpm](https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/) since version 38.
|
||||
|
||||
(interop-section)=
|
||||
(interoperability)=
|
||||
### Interoperability
|
||||
|
||||
OpenPGP was standardized in 1997 to encourage development of interoperable implementations. This has already been a success early on, but in recent years, there has been [much development of new implementations](major-implementations).
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Transferable secret keys are sometimes colloquially referred to as "OpenPGP priv
|
|||
|
||||
Historically, the concept of TSKs, which combine all elements of an OpenPGP certificate with the associated private key material, has sometimes been conflated with OpenPGP private key operations. However, TSKs are primarily a format for storage and transport; it is generally considered inappropriate as a data structure for use in a private keystore. For further details, see {ref}`key-store-design`.
|
||||
|
||||
(encrypted-secrets)=
|
||||
(protected-private-keys)=
|
||||
## Protecting keys with passphrases
|
||||
|
||||
In the OpenPGP format, private key material can be optionally protected with a [passphrase](https://en.wikipedia.org/wiki/Passphrase).
|
||||
|
|
@ -106,7 +106,7 @@ Commonly, when creating a certificate, the user's software will use the same enc
|
|||
|
||||
However, variations are possible, such as when adding new subkeys to an existing certificate. In such cases, a user might choose a different passphrase, or the software might select a different encryption mechanism, for instance, for updated best practices.
|
||||
|
||||
(card-priv)=
|
||||
(openpgp-card)=
|
||||
## OpenPGP cards for private keys
|
||||
|
||||
[OpenPGP cards](https://en.wikipedia.org/wiki/OpenPGP_card) represent a category of hardware security devices specifically designed to handle OpenPGP private key material. These cards offer an alternative to directly managing private key material on the user's computer.
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ The {term}`signature packet<OpenPGP Signature Packet>` consists of two parts:
|
|||
Creating a {term}`signature<OpenPGP Signature Packet>` in OpenPGP
|
||||
```
|
||||
|
||||
(sig-verify)=
|
||||
(signature-verify)=
|
||||
### Verifying an OpenPGP signature packet
|
||||
|
||||
Verifying an {term}`OpenPGP signature packet` is similar to its creation, with some crucial differences that facilitate the {term}`verification` by entities other than the {term}`signer`.
|
||||
|
|
@ -134,7 +134,7 @@ They are formatted as key-value pairs, where the keys are defined as [subpacket
|
|||
- The [*issuer fingerprint*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#issuer-fingerprint-subpacket) {term}`subpacket<OpenPGP Signature Subpacket>` encodes the {term}`fingerprint<OpenPGP Fingerprint>` of the {term}`component key` that issued the {term}`signature<OpenPGP Signature Packet>`.
|
||||
- The [*key flags*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) {term}`subpacket<OpenPGP Signature Subpacket>` defines the {term}`capabilities<capability>` that are assigned to a {term}`component key` within a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
(hashed-and-unhashed-signature-subpackets)=
|
||||
(subpacket-areas)=
|
||||
### Hashed and unhashed signature subpackets
|
||||
|
||||
{term}`Signature subpackets<OpenPGP Signature Subpacket>` within OpenPGP can reside in one of two distinct areas of a {term}`signature packet<OpenPGP Signature Packet>`, each serving a different purpose.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ In another instance:
|
|||
- *When issued as a {term}`self-signature`*, a [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) sets {term}`preferences<Algorithm Preferences>` and advertises {term}`features<Features Subpacket>` applicable to the entire {term}`certificate<OpenPGP Certificate>`.
|
||||
- *When issued by a {term}`third party<Third-party Signature>`*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) {term}`subpacket<OpenPGP Signature Subpacket>`, a similar {term}`direct key signature` {term}`delegates<Delegation>` trust to the signed {term}`certificate<OpenPGP Certificate>`. This may designate the signed {term}`certificate<OpenPGP Certificate>` as a {term}`trust anchor` within the {term}`issuer`'s {term}`Web of Trust`.
|
||||
|
||||
(binding-sigs)=
|
||||
(binding-signatures)=
|
||||
## Self-signatures in certificate formation and management
|
||||
|
||||
{term}`Self-signatures<Self-signature>` play a crucial role in forming and managing the structure of {term}`OpenPGP certificates<OpenPGP certificate>`. These act as *{term}`binding signatures<Binding Signature>`*, joining {term}`components<Component>` and embedding {term}`metadata`.
|
||||
|
|
@ -81,7 +81,7 @@ Conversely, omissions of {term}`packets<Packet>` by third parties can easily occ
|
|||
|
||||
However, there are legitimate instances in which third parties add "unbound" {term}`packets<Packet>` (i.e., not signed by the {term}`certificate<OpenPGP Certificate>`'s {term}`owner<Certificate Holder>`) to a {term}`certificate<OpenPGP Certificate>`:
|
||||
|
||||
- [Third-party certifications](third-party-cert) are often stored within the {term}`packet` data of the {term}`certificate<OpenPGP Certificate>` to which they are related. This is a standard practice that provides convenience for users by allowing easy access to all relevant {term}`certifications<Certification>`. (See {ref}`cert-flooding` for discussion of a related pitfall.)
|
||||
- [Third-party certifications](third-party-certifications) are often stored within the {term}`packet` data of the {term}`certificate<OpenPGP Certificate>` to which they are related. This is a standard practice that provides convenience for users by allowing easy access to all relevant {term}`certifications<Certification>`. (See [](keyserver-flooding) for discussion of a related pitfall.)
|
||||
- {term}`OpenPGP software<OpenPGP Implementation>` may locally add [unbound identity data](unbound-user-ids) to a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
(bind-subkey)=
|
||||
|
|
@ -91,7 +91,7 @@ However, there are legitimate instances in which third parties add "unbound" {te
|
|||
|
||||
A {term}`subkey binding signature` binds a {term}`subkey<OpenPGP Subkey>` to a {term}`primary key<OpenPGP Primary Key>`, and it embeds {term}`metadata` into the {term}`signature packet<OpenPGP Signature Packet>`. Once generated, the {term}`subkey binding signature` {term}`packet` is stored in the {term}`certificate<OpenPGP Certificate>` directly after the {term}`subkey<OpenPGP Subkey>` it binds.
|
||||
|
||||
{term}`Subkeys<OpenPGP Subkey>` designated for signing purposes, identified by the *{term}`signing<Signing Key Flag>`* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags), represent a unique category and are handled differently. See {numref}`bind-subkey-sign`.
|
||||
{term}`Subkeys<OpenPGP Subkey>` designated for signing purposes, identified by the *{term}`signing<Signing Key Flag>`* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags), represent a unique category and are handled differently. See {numref}`bind-signing-subkey`.
|
||||
|
||||
```{figure} plain_svg/subkey_binding_signature.svg
|
||||
:name: fig-subkey-binding-signature
|
||||
|
|
@ -108,7 +108,7 @@ The {term}`validity<Validation>` of a {term}`subkey<OpenPGP Subkey>` is intrinsi
|
|||
Legally, a {term}`subkey<OpenPGP Subkey>` may not have a specified {term}`expiration time`. In such cases, its {term}`expiration` aligns implicitly with that of the {term}`primary key<OpenPGP Primary Key>`. Additionally, the {term}`creation time` of a {term}`subkey<OpenPGP Subkey>` must always be more recent than that of the {term}`primary key<OpenPGP Primary Key>`.
|
||||
```
|
||||
|
||||
(bind-subkey-sign)=
|
||||
(bind-signing-subkey)=
|
||||
### Special case: Binding signing subkeys
|
||||
|
||||
{term}`Binding` {term}`subkeys<OpenPGP Subkey>` that possess the *{term}`signing<Signing Key Flag>`* {term}`key flag` to a {term}`certificate<OpenPGP Certificate>` represents a unique scenario. While similar to the {term}`binding process<Binding>` of other {term}`subkeys<OpenPGP Subkey>`, there is an additional, critical requirement: mutual association.
|
||||
|
|
@ -131,7 +131,7 @@ Linking an {term}`OpenPGP signing subkey` to the {term}`primary key<OpenPGP Prim
|
|||
|
||||
The {term}`back signature<Primary Key Binding Signature>` signifies the mutuality of the {term}`subkey<OpenPGP Subkey>`'s association with the {term}`primary key<OpenPGP Primary Key>` and is embedded as {term}`subpacket<OpenPGP Signature Subpacket>` data within the {term}`subkey binding signature`, reinforcing the {term}`authenticity<Authentication>` of the {term}`binding`.
|
||||
|
||||
(bind-ident)=
|
||||
(bind-identity)=
|
||||
### Binding identities to a certificate
|
||||
|
||||
{term}`Self-signatures<Self-signature>` also play a vital role in {term}`binding` {term}`identity components<Identity Component>`, such as {term}`User IDs<User ID>` or {term}`User Attributes<User Attribute>`, to an {term}`OpenPGP certificate`.
|
||||
|
|
@ -173,7 +173,7 @@ The types of {term}`metadata` typically associated with the {term}`certificate<O
|
|||
|
||||
A [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) serves as the [preferred mechanism](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-9) in OpenPGP v6 for defining {term}`metadata` for the entire {term}`certificate<OpenPGP Certificate>`, by associating it with the {term}`primary key<OpenPGP Primary Key>`.
|
||||
|
||||
(self-signature-binding-to-primary-user-id)=
|
||||
(primary-user-id-binding)=
|
||||
#### Self-signature binding to primary User ID
|
||||
|
||||
In OpenPGP v4, another mechanism was often used for {term}`metadata` management: integrating global {term}`certificate<OpenPGP Certificate>` {term}`metadata` within a {term}`User ID binding signature`. This is specifically evident in the {term}`binding signature` of the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id) of the {term}`OpenPGP certificate`.
|
||||
|
|
@ -215,7 +215,7 @@ Note: {term}`certification signatures<Certification>` [can be made irrevocable](
|
|||
A {term}`revocation signature packet` lacking a {term}`Reason for Revocation subpacket` is interpreted as a {term}`hard revocation`.
|
||||
```
|
||||
|
||||
(third-party-cert)=
|
||||
(third-party-certifications)=
|
||||
## Authentication and delegation in third-party signatures
|
||||
|
||||
{term}`Third-party signatures<Third-party Signature>` in OpenPGP primarily encode {term}`authentication` statements for {term}`identities<Identity>` and {term}`delegate<Delegation>` trust decisions. These {term}`signatures<OpenPGP Signature Packet>` can be manually inspected or processed as machine-readable artifacts by {term}`OpenPGP software<OpenPGP Implementation>`, which evaluates the {term}`authenticity<Authentication>` of {term}`certificates<OpenPGP Certificate>` based on user-specified {term}`trust anchors<Trust Anchor>`.
|
||||
|
|
@ -238,7 +238,7 @@ OpenPGP uses [*trust signature*](https://www.ietf.org/archive/id/draft-ietf-open
|
|||
- {term}`identity certification signatures<Identity Certification>` ({term}`type ID<Signature Type ID>` `0x10` - `0x13`)
|
||||
- [direct key signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) ({term}`type ID<Signature Type ID>` `0x1F`)
|
||||
|
||||
(trust-depth-level)=
|
||||
(trust-level)=
|
||||
#### Trust depth/level
|
||||
|
||||
The "{term}`trust depth`" (or {term}`level<Trust Depth>`) in OpenPGP signifies the extent of transitive {term}`delegation` within the {term}`authentication` process. It determines how far a {term}`delegation` can be extended from the original {term}`trusted introducer` to subsequent intermediaries. Essentially, a {term}`certificate<OpenPGP Certificate>` with a {term}`trust depth` of more than one acts as a "{term}`meta-introducer`," facilitating {term}`authentication` decisions across multiple levels in the network.
|
||||
|
|
@ -249,14 +249,14 @@ However, when the {term}`trust depth` is set higher, it implies a chain of {term
|
|||
|
||||
This allows for a more extensive network of trusted {term}`certifications<Certification>`, enabling a broader and more interconnected {term}`Web of Trust`.
|
||||
|
||||
(trust-amounts)=
|
||||
(trust-amount)=
|
||||
#### Trust amounts
|
||||
|
||||
The "{term}`trust amount`," with a numerical value ranging from `0` to `255`, quantifies the degree of reliance on a {term}`delegation`.
|
||||
|
||||
A higher value indicates greater degree of reliance. This quantification aids {term}`OpenPGP software<OpenPGP Implementation>` in determining an aggregate amount of reliance, based on combined {term}`certifications<Certification>` from multiple {term}`trusted introducers<Trusted Introducer>`.
|
||||
|
||||
(limiting-delegation-scope)=
|
||||
(trust-scope)=
|
||||
#### Limiting delegation scope
|
||||
|
||||
When using *{term}`trust signature`* {term}`subpackets<OpenPGP Signature Subpacket>`, a {term}`delegation` can be limited to {term}`identities<Identity>` that match a [*regular expression*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#regex-subpacket).
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Note that {term}`data signatures<Data Signature>` are distinct from [](/signing_
|
|||
|
||||
{term}`Data signature packets<Data Signature Packet>` manifest in three distinct forms, which will be detailed in the subsequent section.
|
||||
|
||||
(forms-of-openpgp-data-signatures)=
|
||||
(forms-of-data-signatures)=
|
||||
## Forms of OpenPGP data signatures
|
||||
|
||||
{term}`OpenPGP data signatures<Data Signature>` can be applied in three distinct forms[^sign-modes-gpg]:
|
||||
|
|
@ -82,7 +82,7 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin
|
|||
|
||||
Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature<OpenPGP Signature Packet>` successfully.
|
||||
|
||||
(cleartext-sig)=
|
||||
(cleartext-signature)=
|
||||
### Cleartext signatures
|
||||
|
||||
The *{term}`Cleartext Signature Framework`* (CSF) in OpenPGP accomplishes two primary objectives:
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Some signatures can be verified standalone, while others require the verificatio
|
|||
|
||||
## When are signatures valid?
|
||||
|
||||
As a necessary condition, a valid signature must be [cryptographically correct](sig-verify). This means that both the signature and its signed input data must be intact.
|
||||
As a necessary condition, a valid signature must be [cryptographically correct](signature-verify). This means that both the signature and its signed input data must be intact.
|
||||
|
||||
However, there is a difference between signature *correctness* and *validity*:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Starting from [Alice's OpenPGP private key](alice-priv), we first produce the co
|
|||
$ sq key extract-cert alice.priv > alice.pub
|
||||
```
|
||||
|
||||
(split-alice)=
|
||||
(zoom-split-alice)=
|
||||
### Splitting the OpenPGP certificate into packets
|
||||
|
||||
To create a very minimal version of Alice's certificate, we will split the data in `alice.pub` into its component packets and reassemble only the relevant ones back into a new variant.
|
||||
|
|
@ -109,7 +109,7 @@ $ sq packet dump --hex alice_minimal.pub
|
|||
|
||||
This will allow us to gain a detailed understanding of the packet contents.
|
||||
|
||||
(public-key)=
|
||||
(zoom-public-key)=
|
||||
### Public-Key packet
|
||||
|
||||
The output begins with a (primary) [Public-Key packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-key-packet-formats):
|
||||
|
|
@ -169,7 +169,7 @@ Note that the *Public-Key packet* contains only the public part of the key.
|
|||
Structure of a Public-Key packet.
|
||||
```
|
||||
|
||||
(zooming-in-dks)=
|
||||
(zoom-dks)=
|
||||
### Direct Key Signature
|
||||
|
||||
The next packet in the certificate is a [*Direct Key Signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-direct-key), which plays a crucial role in binding specific information to the primary key. This signature is contained within the file `alice.pub-1--Signature`.
|
||||
|
|
@ -361,7 +361,7 @@ The signature is calculated from this hash digest.
|
|||
Structure of a direct key signature packet.
|
||||
```
|
||||
|
||||
(zoom-enc-subkey)=
|
||||
(zoom-subkey-enc)=
|
||||
## Encryption subkey
|
||||
|
||||
Let's now look at a subkey in Alice's OpenPGP certificate. A subkey, when linked to an OpenPGP certificate via its primary key, consists of two elements:
|
||||
|
|
@ -378,7 +378,7 @@ It's common to look at a packet dump for a full OpenPGP certificate as shown bel
|
|||
$ sq packet dump --hex alice.pub
|
||||
```
|
||||
|
||||
This command shows the details for the full series of packets in an OpenPGP certificate (refer to the list of [packets of Alice's certificate](split-alice)). Finding a particular packet in that list can take a bit of focus and practice though.
|
||||
This command shows the details for the full series of packets in an OpenPGP certificate (refer to the list of [packets of Alice's certificate](zoom-split-alice)). Finding a particular packet in that list can take a bit of focus and practice though.
|
||||
|
||||
In the following sections,we make it easier for ourselves by directly examining individual packets from the files we created with `sq packet split` above.
|
||||
````
|
||||
|
|
@ -408,7 +408,7 @@ Public-Subkey Packet, new CTB, 2 header bytes + 42 bytes
|
|||
00000020 35 2a 46 01 f3 cc 00 f5 4a 09 3e 3f
|
||||
```
|
||||
|
||||
Notice that the structure of this *Public-Subkey packet* mirrors the primary key's [*Public-Key packet*](public-key) above. However, there are notable differences between the two packets:
|
||||
Notice that the structure of this *Public-Subkey packet* mirrors the primary key's [*Public-Key packet*](zoom-public-key) above. However, there are notable differences between the two packets:
|
||||
|
||||
- The packet type ID (`CTB`) in this packet shows type 14 ([*Public-Subkey packet*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-subkey-packet-type-i)).
|
||||
|
||||
|
|
@ -619,7 +619,7 @@ Signature Packet, new CTB, 3 header bytes + 325 bytes
|
|||
00000140 a6 73 c8 33 5a 9c d9 0a
|
||||
```
|
||||
|
||||
(zooming-in-user-id)=
|
||||
(zoom-user-id)=
|
||||
## Adding an identity component
|
||||
|
||||
In this section, we'll look at an identity associated with Alice's certificate.
|
||||
|
|
@ -653,7 +653,7 @@ Essentially, a User ID packet is just a string marked as a User ID by the packet
|
|||
|
||||
### Linking the User ID with a certification self-signature
|
||||
|
||||
Similar to [linking a subkey](zoom-enc-subkey) to the OpenPGP certificate, a self-signature is used to connect this new component to the certificate.
|
||||
Similar to [linking a subkey](zoom-subkey-enc) to the OpenPGP certificate, a self-signature is used to connect this new component to the certificate.
|
||||
|
||||
To bind identities to a certificate with a self-signature, signature types `0x10` - `0x13` can be used. Here, the signature type `0x13` (*positive certification*) is used.
|
||||
|
||||
|
|
@ -730,7 +730,7 @@ Signature Packet, new CTB, 2 header bytes + 185 bytes
|
|||
```
|
||||
|
||||
|
||||
Because this packet structure closely mirrors the [Direct Key Signature](zooming-in-dks) discussed above, we will cover this succinctly.
|
||||
Because this packet structure closely mirrors the [Direct Key Signature](zoom-dks) discussed above, we will cover this succinctly.
|
||||
|
||||
We're again looking at a Signature packet. Its `type` is `0x13` ([corresponding to a *positive certification* signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types)).
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ Secret-Key Packet, new CTB, 2 header bytes + 75 bytes
|
|||
00000040 bd 42 dd 4b e9 a3 36 81 3b a5 cc cf fb
|
||||
```
|
||||
|
||||
The Secret-Key packet consists in large part of the actual cryptographic key data. Notice that its content is almost entirely the same as the Public-Key packet [seen in the previous chapter](public-key). Let's look at the packet field by field:
|
||||
The Secret-Key packet consists in large part of the actual cryptographic key data. Notice that its content is almost entirely the same as the Public-Key packet [seen in the previous chapter](zoom-public-key). Let's look at the packet field by field:
|
||||
|
||||
- `CTB: 0xc5`[^CTB]: The [packet type ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-headers) for this packet. The binary representation of the value `0xc5` is `11000101`. Bits 7 and 6 show that the packet is in *OpenPGP packet format* (as opposed to in *Legacy packet format*). The remaining 6 bits encode the type ID's value: "5". This is the value for a Secret-Key packet, as shown in the list of [packet type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-types).
|
||||
- `length: 0x4b`: The remaining length of this packet.
|
||||
|
|
@ -90,7 +90,7 @@ Note that the *Secret-Key packet* contains both the private and the public part
|
|||
|
||||
### Secret-Subkey packet
|
||||
|
||||
Further down in the "packet dump" of Alice's key, we see the encryption subkey, which we already inspected in its Public-Subkey packet format, [above](zoom-enc-subkey):
|
||||
Further down in the "packet dump" of Alice's key, we see the encryption subkey, which we already inspected in its Public-Subkey packet format, [above](zoom-subkey-enc):
|
||||
|
||||
```text
|
||||
Secret-Subkey Packet, new CTB, 2 header bytes + 75 bytes
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue