mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-09 11:19:41 +02:00
Add glossary entries and links for chapter 1 - 4 and 6
Signed-off-by: David Runge <dave@sleepmap.de>
This commit is contained in:
David Runge
parent
840d6bdd0f
commit
9848143e77
6 changed files with 531 additions and 184 deletions
|
|
@ -18,8 +18,8 @@ OpenPGP is an open standard for cryptographic operations. It is a system based o
|
|||
With OpenPGP, you can:
|
||||
|
||||
- [Encrypt](encryption_chapter) and [decrypt](decryption_chapter) messages to preserve confidentiality
|
||||
- [Sign](signing_data) and [verify](verification_chapter) data to ensure authenticity
|
||||
- [Issue and validate certifications](component_signatures_chapter) about keys and identities, similar to the role of a Certificate Authority in validating identities.
|
||||
- [Sign](signing_data) and [verify](verification_chapter) data to ensure {term}`authenticity<Authentication>`
|
||||
- [Issue and validate certifications](component_signatures_chapter) about {term}`keys<Key>` and {term}`identities<Identity>`, similar to the role of a {term}`Certificate Authority<Certification Authority>` ({term}`CA<Certification Authority>`) in validating {term}`identities<Identity>`.
|
||||
|
||||
## Who is the audience for this document?
|
||||
|
||||
|
|
@ -42,11 +42,11 @@ The goal of this document is to offer an implementation-independent introduction
|
|||
The [OpenPGP RFC](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/)
|
||||
defines *the message formats used in OpenPGP.* That is, it describes the internal structure of OpenPGP data, which is crucial for OpenPGP library implementers. However, this level of detail is not required for software developers who use OpenPGP via a library.
|
||||
|
||||
This document describes OpenPGP concepts at the "library" level of abstraction, omitting unnecessary detail about the internal encoding of OpenPGP artifacts. Instead, we focus on the properties of these OpenPGP artifacts and how they are used, while adding context that is not elaborated on in the RFC.
|
||||
This document describes OpenPGP concepts at the "library" level of abstraction, omitting unnecessary detail about the internal encoding of OpenPGP artifacts. Instead, we focus on the properties of these OpenPGP artifacts and how they are used, while adding context that is not elaborated on in the [RFC](https://en.wikipedia.org/wiki/Request_for_Comments).
|
||||
|
||||
## Which version of OpenPGP does this address?
|
||||
|
||||
The documentation mainly covers version 6 of OpenPGP, while occasionally noting differences to previous versions that are relevant to application developers.
|
||||
|
||||
Version 4 of OpenPGP will remain relevant for a number of years;
|
||||
some version 3 artifacts are still in use as of this writing.
|
||||
some version 3 artifacts are still in use as of this writing.
|
||||
|
|
|
|||
|
|
@ -11,11 +11,11 @@ OpenPGP is a widely recognized, IETF-standardized set of cryptographic operation
|
|||
|
||||
There are other compelling reasons for why you might consider using OpenPGP in your project:
|
||||
|
||||
1. **Decentralized trust model**: OpenPGP's decentralization defines mechanisms for authentication that allow individuals and entities to create and manage their own cryptographic identities. Unlike centralized trust models, decentralized trust models empower individuals and entities to manage their own identities, fostering a community-driven web of trust instead of relying on a centralized authority, thus reducing single points of failure.
|
||||
1. **Decentralized trust model**: OpenPGP's decentralization defines mechanisms for {term}`authentication` that allow individuals and entities to create and manage their own cryptographic {term}`identities<Identity>`. Unlike centralized {term}`trust models<Trust Model>`, decentralized {term}`trust models<Trust Model>` empower individuals and entities to manage their own {term}`identities<Identity>`, fostering a community-driven web of trust instead of relying on a centralized authority, thus reducing single points of failure.
|
||||
|
||||
2. **End-to-end encryption**: OpenPGP provides a robust framework for implementing end-to-end encryption. Content remains confidential, verifiable, authenticated, and protected against unauthorized access, even when the communication channel itself might be otherwise compromised. Encryption is crucial in a myriad of scenarios, particularly when transmitting sensitive information such as financial data, personally identifiable information (PII), or proprietary business data.
|
||||
2. **End-to-end encryption**: OpenPGP provides a robust framework for implementing end-to-end encryption. Content remains confidential, verifiable, {term}`authenticated<Authentication>`, and protected against unauthorized access, even when the communication channel itself might be otherwise compromised. Encryption is crucial in a myriad of scenarios, particularly when transmitting sensitive information such as financial data, personally identifiable information (PII), or proprietary business data.
|
||||
|
||||
3. **Anonymity and pseudonymity**: In sensitive and volatile situations where identity protection is crucial, OpenPGP can be used to provide a level of anonymity or pseudonymity that helps protect user identities. For example, OpenPGP has been used alongside other privacy tools, such as Tor and VPNs, to provide secure and anonymous communication for whistleblowers, human rights lawyers, activists in repressive regimes, and journalists, reducing their risks for retaliation and state violence.
|
||||
3. **Anonymity and pseudonymity**: In sensitive and volatile situations where identity protection is crucial, OpenPGP can be used to provide a level of anonymity or pseudonymity that helps protect user identities. For example, OpenPGP has been used alongside other privacy tools, such as [Tor](https://en.wikipedia.org/wiki/The_Tor_Project) and [VPN](https://en.wikipedia.org/wiki/Virtual_private_network)s, to provide secure and anonymous communication for whistleblowers, human rights lawyers, activists in repressive regimes, and journalists, reducing their risks for retaliation and state violence.
|
||||
|
||||
4. **Interoperability**: OpenPGP is a well-structured and standardized protocol, widely adopted by various public and private entities but not tied to any particular vendor's technology. It supports all major operating systems, such as Windows, macOS, GNU/Linux, Android, and iOS. Because of standardization, wide adoption, cross-platform compatibility, and adaptability, OpenPGP's interoperability significantly contributes to reducing development time, costs, and technical hurdles.
|
||||
|
||||
|
|
@ -100,12 +100,12 @@ Initial efforts to incorporate support for OpenPGP version 6 have been undertake
|
|||
|
||||
### Post-quantum cryptography in OpenPGP
|
||||
|
||||
There is [ongoing work](https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/) to standardize and add support for post-quantum public-key algorithms in OpenPGP. This project is funded by the [german "BSI"](https://en.wikipedia.org/wiki/Federal_Office_for_Information_Security). Goals include adding support for post-quantum cryptography to Thunderbird and GnuPG. A [presentation](https://datatracker.ietf.org/meeting/113/materials/slides-113-openpgp-a-post-quantum-approach-for-openpgp-00) was given at [IETF 113](https://datatracker.ietf.org/meeting/113/session/openpgp/).
|
||||
There is [ongoing work](https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/) to standardize and add support for post-quantum {term}`public-key algorithms<Public Key Algorithm>` in OpenPGP. This project is funded by the [german "BSI"](https://en.wikipedia.org/wiki/Federal_Office_for_Information_Security). Goals include adding support for post-quantum cryptography to Thunderbird and GnuPG. A [presentation](https://datatracker.ietf.org/meeting/113/materials/slides-113-openpgp-a-post-quantum-approach-for-openpgp-00) was given at [IETF 113](https://datatracker.ietf.org/meeting/113/session/openpgp/).
|
||||
|
||||
## Zooming in: Internal structure of OpenPGP data
|
||||
|
||||
OpenPGP data is internally structured as "packets." We'll look into examples of this internal structure in a series of chapters at the end of this document.
|
||||
|
||||
Getting familiar with the internal format of OpenPGP data provides practical insight into the [RFC](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/), which describes the internal structure of OpenPGP packets in full detail, and may also come in handy for debugging issues.
|
||||
Getting familiar with the internal format of OpenPGP data provides practical insight into the [RFC](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/), which describes the internal structure of OpenPGP {term}`packets<Packet>` in full detail, and may also come in handy for debugging issues.
|
||||
|
||||
(Most of the time, however, we will look at OpenPGP artifacts at a higher level of abstraction.)
|
||||
|
|
|
|||
|
|
@ -16,11 +16,12 @@ 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 codes
|
||||
|
||||
A [message authentication code](https://en.wikipedia.org/wiki/Message_authentication_code) (MAC), also known as an authentication tag, is a small piece of information used to verify the integrity and authenticity of a message.
|
||||
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.
|
||||
|
||||
It is derived from the original message using a (symmetric) secret key. The recipient of a message containing a MAC, who is also in possession of the secret key, can verify that the message has not been altered.
|
||||
It is derived from the original message using a {term}`(symmetric) secret key<Symmetric Secret Key>`. The recipient of a message containing a MAC, who is also in possession of the secret key, can verify that the message has not been altered.
|
||||
|
||||
[HMAC](https://en.wikipedia.org/wiki/HMAC) is a type of MAC that relies on a hash function. It is used in the OpenPGP protocol.
|
||||
|
||||
|
|
@ -33,6 +34,7 @@ A notable KDF for the OpenPGP specification is the [HKDF](https://en.wikipedia.o
|
|||
|
||||
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.
|
||||
|
||||
(symmetric_key_cryptography)=
|
||||
## Symmetric-key cryptography
|
||||
|
||||
[Symmetric-key cryptography](https://en.wikipedia.org/wiki/Symmetric-key_algorithm) uses the same cryptographic key for both encryption and decryption, unlike asymmetric cryptography where a pair of keys is used: a public key for encryption and a corresponding private key for decryption. Symmetric-key cryptographic systems support *encryption/decryption* operations.
|
||||
|
|
@ -80,6 +82,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 (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.
|
||||
|
|
@ -98,9 +101,9 @@ Throughout this document, we will frequently reference asymmetric cryptographic
|
|||
An asymmetric cryptographic key pair
|
||||
```
|
||||
|
||||
Each key pair comprises two parts: the public key and the private key. For ease of identification in this documentation, the public key will be shown in green and the private key in red. Additionally, public keys are depicted with a solid border and pointing to the right, while private keys are shown with a dotted border and pointing to the left.
|
||||
Each key pair comprises two parts: the {term}`public key<OpenPGP Certificate>` and the {term}`private key<Transferable Secret Key>`. For ease of identification in this documentation, the {term}`public key<OpenPGP Certificate>` will be shown in green and the private key in red. Additionally, {term}`public keys<OpenPGP Certificate>` are depicted with a solid border and pointing to the right, while {term}`private keys<Transferable Secret Key>` are shown with a dotted border and pointing to the left.
|
||||
|
||||
It's important to note that in many scenarios, only the public key is exposed or used. These situations will be elaborated upon in subsequent sections of this document.
|
||||
It's important to note that in many scenarios, only the {term}`public key<OpenPGP Certificate>` is exposed or used. These situations will be elaborated upon in subsequent sections of this document.
|
||||
|
||||
```{figure} diag/public_key.png
|
||||
:name: fig-public-key
|
||||
|
|
@ -111,7 +114,7 @@ The public part of an asymmetric key pair
|
|||
|
||||
### Usage and terminology in OpenPGP
|
||||
|
||||
OpenPGP extensively uses public-key cryptography for encryption and digital signing operations.
|
||||
OpenPGP extensively uses {term}`public-key cryptography<Public Key Algorithm>` for encryption and digital signing operations.
|
||||
|
||||
```{admonition} Terminology
|
||||
:class: note
|
||||
|
|
@ -123,11 +126,11 @@ While "secret key" (as used in the OpenPGP RFC) and "private key" serve the same
|
|||
|
||||
### Cryptographic digital signatures
|
||||
|
||||
[Digital signatures](https://en.wikipedia.org/wiki/Digital_signature) are a fundamental mechanism of asymmetric cryptography, providing secure, mathematical means to validate the authenticity, integrity, and origin of digital messages and documents.
|
||||
[Digital signatures](https://en.wikipedia.org/wiki/Digital_signature) are a fundamental mechanism of {term}`asymmetric cryptography`, providing secure, mathematical means to validate the {term}`authenticity<Authentication>`, integrity, and origin of digital messages and documents.
|
||||
|
||||
In OpenPGP, digital signatures have diverse applications, extending beyond mere validation of a message's origin. They can signify various intents, including certification, consent, acknowledgment, or even revocation by the signer. The multifaceted nature of "statements" conveyed through digital signatures in cryptographic protocols is wide-ranging but crucial, allowing third parties to inspect/evaluate these statements for authenticity and intended purpose.
|
||||
In OpenPGP, digital signatures have diverse applications, extending beyond mere validation of a message's origin. They can signify various intents, including {term}`certification`, consent, acknowledgment, or even revocation by the signer. The multifaceted nature of "statements" conveyed through {term}`digital signatures<OpenPGP Signature Packet>` in cryptographic protocols is wide-ranging but crucial, allowing third parties to inspect/evaluate these statements for {term}`authenticity<Authentication>` and intended purpose.
|
||||
|
||||
Digital signatures in OpenPGP are used in two primary contexts:
|
||||
{term}`Digital signatures<OpenPGP Signature Packet>` in OpenPGP are used in two primary contexts:
|
||||
|
||||
- [Data signatures](signing_data)
|
||||
- [Signatures on components](component_signatures_chapter)
|
||||
|
|
@ -135,8 +138,8 @@ Digital signatures in OpenPGP are used in two primary contexts:
|
|||
(hybrid_cryptosystems)=
|
||||
## Hybrid cryptosystems
|
||||
|
||||
[Hybrid cryptosystems](https://en.wikipedia.org/wiki/Hybrid_cryptosystem) combine the use of symmetric and asymmetric (public-key) cryptography to capitalize on the strengths of each, namely symmetric cryptography's speed and efficiency and public-key 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 (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
|
||||
|
||||
OpenPGP uses a hybrid cryptosystem for encryption. This approach involves generating unique shared secrets, known as "session keys," for each session. For detailed information on this topic, please refer to the chapters {ref}`encryption_chapter` and {ref}`decryption_chapter`.
|
||||
OpenPGP uses a {term}`hybrid cryptosystem` for encryption. This approach involves generating unique shared secrets, known as "session keys," for each session. For detailed information on this topic, please refer to the chapters {ref}`encryption_chapter` and {ref}`decryption_chapter`.
|
||||
|
|
|
|||
|
|
@ -6,224 +6,232 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
(certificates_chapter)=
|
||||
# Certificates
|
||||
|
||||
OpenPGP fundamentally hinges on the concept of "OpenPGP certificates," also known as "OpenPGP public keys." These certificates are complex data structures essential for identity verification, data encryption, and digital signatures. Understanding their structure and function is pivotal to effectively applying the OpenPGP standard.
|
||||
OpenPGP fundamentally hinges on the concept of "{term}`OpenPGP certificates<OpenPGP Certificate>`," also known as "{term}`OpenPGP public keys<OpenPGP Public Key>`." These {term}`certificates<OpenPGP Certificate>` are complex data structures essential for {term}`identity verification`, data encryption, and {term}`digital signatures<OpenPGP Signature Packet>`. Understanding their structure and function is pivotal to effectively applying the OpenPGP standard.
|
||||
|
||||
An OpenPGP certificate, by definition, does not contain private key material.
|
||||
An {term}`OpenPGP certificate`, by definition, does not contain {term}`private key material`.
|
||||
|
||||
Fundamentally, the effective management of certificates and a thorough grasp of their authentication and trust models are crucial for proficient OpenPGP usage. Although this document offers just a brief overview of these aspects, they form a fundamental part of the broader OpenPGP framework and warrant further study.
|
||||
Fundamentally, the effective management of {term}`certificates<OpenPGP Certificate>` and a thorough grasp of their {term}`authentication` and {term}`trust models<Trust Model>` are crucial for proficient OpenPGP usage. Although this document offers just a brief overview of these aspects, they form a fundamental part of the broader OpenPGP framework and warrant further study.
|
||||
|
||||
- For an in-depth exploration of OpenPGP's private key material, refer to {ref}`private_key_chapter`. This chapter provides essential insights into private key management and security practices.
|
||||
- For an in-depth exploration of OpenPGP's {term}`private key material`, refer to {ref}`private_key_chapter`. This chapter provides essential insights into {term}`private key<Transferable Secret Key>` management and security practices.
|
||||
|
||||
- The bindings that link the components of a certificate are comprehensively discussed in {ref}`component_signatures_chapter`, offering a deeper understanding of certificate structure and integrity.
|
||||
- The bindings that link the {term}`components<Component>` of a {term}`certificate<OpenPGP Certificate>` are comprehensively discussed in {ref}`component_signatures_chapter`, offering a deeper understanding of {term}`certificate<OpenPGP Certificate>` structure and integrity.
|
||||
|
||||
- Finally, our chapter {ref}`zoom_certificates` discusses the internal structure of certificates in detail.
|
||||
- Finally, our chapter {ref}`zoom_certificates` discusses the internal structure of {term}`certificates<OpenPGP Certificate>` in detail.
|
||||
|
||||
## Terminology: Understanding "keys"
|
||||
|
||||
The term "(cryptographic) keys" is central to grasping the concept of OpenPGP certificates. However, it can refer to different entities, making it a potentially confusing term. Let's clarify those differences.
|
||||
The term "{term}`(cryptographic) keys<Cryptographic Key>`" is central to grasping the concept of {term}`OpenPGP certificates<OpenPGP certificate>`. However, it can refer to different entities, making it a potentially confusing term. Let's clarify those differences.
|
||||
|
||||
### Public vs. private keys
|
||||
|
||||
The term "key," without additional context, can refer to either public or private asymmetric key material. Additionally, symmetric keys may be used in OpenPGP to encrypt private key material, adding a layer of security and complexity.
|
||||
The term "{term}`key`," without additional context, can refer to either public or private {term}`asymmetric<Asymmetric Cryptography>` key material. Additionally, {term}`symmetric<Symmetric Cryptography>` keys may be used in OpenPGP to encrypt {term}`private key material`, adding a layer of security and complexity.
|
||||
|
||||
(layers_of_keys_in_openpgp)=
|
||||
### Layers of keys in OpenPGP
|
||||
|
||||
In OpenPGP, the term "key" may refer to three distinct layers, each serving a unique purpose:
|
||||
In OpenPGP, the term "{term}`key`" may refer to three distinct layers, each serving a unique purpose:
|
||||
|
||||
1. A (bare) ["cryptographic key"](asymmetric_key_pair) comprises the private and/or public parameters forming a key. For instance, in the case of an RSA private key, the key consists of the exponent `d` along with the prime numbers `p` and `q`.
|
||||
2. An OpenPGP *component key* includes either an "OpenPGP primary key" or an "OpenPGP subkey." It is a building block of an OpenPGP certificate, consisting of a cryptographic keypair coupled with some invariant metadata, such as key creation time.
|
||||
3. An "OpenPGP certificate" (or "OpenPGP key") consists of several component keys, identity components, and other elements. These certificates are dynamic, evolving over time as components are added, expire, or are marked as invalid.
|
||||
1. A (bare) ["cryptographic key"](asymmetric_key_pair) comprises the private and/or public parameters forming a key. For instance, in the case of an RSA {term}`private key<Transferable Secret Key>`, the key consists of the exponent `d` along with the prime numbers `p` and `q`.
|
||||
2. An OpenPGP *{term}`component key<OpenPGP Component Key>`* includes either an "{term}`OpenPGP primary key`" or an "{term}`OpenPGP subkey`." It is a building block of an {term}`OpenPGP certificate`, consisting of a cryptographic keypair coupled with some invariant {term}`metadata`, such as key {term}`creation time`.
|
||||
3. An "{term}`OpenPGP certificate`" (or "OpenPGP key") consists of several {term}`component keys<OpenPGP Component Key>`, {term}`identity components<Identity Component>`, and other elements. These {term}`certificates<Certificate>` are dynamic, evolving over time as {term}`components<Component>` are added, {term}`expire<Expiration>`, or are marked as {term}`invalid<Validation>`.
|
||||
|
||||
The following section will delve into the OpenPGP-specific layers (2 and 3) to provide a clearer understanding of their roles within OpenPGP certificates.
|
||||
The following section will delve into the OpenPGP-specific layers (2 and 3) to provide a clearer understanding of their roles within {term}`OpenPGP certificates<OpenPGP Certificate>`.
|
||||
|
||||
## Structure of OpenPGP certificates
|
||||
|
||||
An OpenPGP certificate (or "OpenPGP key") is a collection of an arbitrary number of elements[^packets]:
|
||||
An {term}`OpenPGP certificate` (or "{term}`OpenPGP key`") is a collection of an arbitrary number of elements[^packets]:
|
||||
|
||||
[^packets]: In technical terms, the elements of an OpenPGP certificate are a collection of "packets." Each component key and identity component is internally represented as a packet. Another common type of packet is the "signature" packet, which connect the components of a certificate.
|
||||
[^packets]: In technical terms, the elements of an {term}`OpenPGP certificate` are a collection of "{term}`packets<Packet>`." Each {term}`component key<OpenPGP Component Key>` and {term}`identity component` is internally represented as a {term}`packet`. Another common type of {term}`packet` is the "{term}`signature`" {term}`packet`, which connect the {term}`components<Component>` of a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
- Component keys
|
||||
- Identity components
|
||||
- Additional metadata, including connections between the certificate's components
|
||||
- {term}`Component keys<OpenPGP Component Key>`
|
||||
- {term}`Identity components<Identity Component>`
|
||||
- Additional {term}`metadata`, including connections between the {term}`certificate<OpenPGP Certificate>`'s {term}`components<Component>`
|
||||
|
||||
This documentation collectively refers to component keys and identity components as "the components of a certificate."
|
||||
This documentation collectively refers to {term}`component keys<OpenPGP Component Key>` and {term}`identity components<Identity Component>` as "the {term}`components<Component>` of a {term}`certificate<OpenPGP Certificate>`."
|
||||
|
||||
```{figure} diag/Components_of_an_OpenPGP_Certificate.svg
|
||||
:name: fig-openpgp-certificate-components
|
||||
:alt: Depicts a box with white background and the title "OpenPGP certificate". In the box several other boxes and accompanying texts, representing component keys and User IDs, are shown. There are three component keys boxes with a green frame, each with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol in the lower right area. All three have a title, a unique fingerprint below the box and a unique capability keyword, perpendicular to the box on the right side. The top-most component key box has a light-green background, with the title "Component Key (primary)" and capability keyword "certification". The second-to-top component key box has a white background, with the title "Component Key" and capability keyword "encryption". The lowest component key box has a white background, with the title "Component Key" and capability keyword "signing". There are two User ID boxes, each with a black frame, open to top left and lower right corner. Both boxes have a user icon on the top left side, the title "User ID" on the top right side and a User ID string at the bottom. The top box has "Alice Adams <alice@example.org>" and the lower box has "Alice" as User ID string.
|
||||
|
||||
Typical components in an OpenPGP certificate
|
||||
Typical {term}`components<Component>` in an {term}`OpenPGP certificate`
|
||||
```
|
||||
|
||||
Every element in an OpenPGP certificate revolves around a central component: the *OpenPGP primary key*. The primary key acts as a personal *certification authority* (CA) for the certificate's owner, enabling cryptographic statements regarding subkeys, identities, expiration, revocation, and more.
|
||||
Every element in an {term}`OpenPGP certificate` revolves around a central {term}`component`: the *{term}`OpenPGP primary key`*. The primary key acts as a personal *{term}`certification authority`* ({term}`CA<Certification Authority>`) for the {term}`certificate<OpenPGP Certificate>`'s owner, enabling cryptographic statements regarding {term}`subkeys<OpenPGP Subkey>`, {term}`identities<Identity>`, {term}`expiration`, {term}`revocation`, and more.
|
||||
|
||||
```{note}
|
||||
OpenPGP certificates tend to have a long lifespan, with the potential for modifications (typically by their owner) over time. Components may be added or invalidated throughout a certificate's lifetime. However, once published, components [cannot be removed](append-only) from certificates.
|
||||
{term}`OpenPGP certificates<OpenPGP Certificate>` tend to have a long lifespan, with the potential for modifications (typically by their owner) over time. {term}`Components<Component>` may be added or {term}`invalidated<Validation>` throughout a {term}`certificate<OpenPGP Certificate>`'s lifetime. However, once published, {term}`components<Component>` [cannot be removed](append-only) from {term}`certificates<OpenPGP Certificate>`.
|
||||
```
|
||||
|
||||
(component_keys)=
|
||||
## Component keys
|
||||
|
||||
An OpenPGP certificate usually contains multiple component keys. Component keys serve in one of two roles: either as an "OpenPGP primary key" or as an "OpenPGP subkey."
|
||||
An {term}`OpenPGP certificate` usually contains multiple {term}`component keys<OpenPGP Component Key>`. {term}`Component keys<OpenPGP Component Key>` serve in one of two roles: either as an "{term}`OpenPGP primary key`" or as an "{term}`OpenPGP subkey`."
|
||||
|
||||
OpenPGP component keys logically consist of an [asymmetric cryptographic keypair](asymmetric_key_pair) and a creation timestamp. Once created, these attributes of a component key remain fixed (for ECDH keys, two additional parameters are part of a component key's constitutive data[^ecdh-parameters]).
|
||||
{term}`OpenPGP component keys<OpenPGP Component Key>` logically consist of an [asymmetric cryptographic keypair](asymmetric_key_pair) and a creation timestamp. Once created, these attributes of a {term}`component key<OpenPGP Component Key>` remain fixed (for ECDH keys, two additional parameters are part of a {term}`component key`'s constitutive data[^ecdh-parameters]).
|
||||
|
||||
[^ecdh-parameters]: For [ECDH](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ecd) component keys, two additional algorithm parameters are integral to the component key's constitutive and immutable properties. Those parameters specify a hash function and a symmetric encryption algorithm.
|
||||
[^ecdh-parameters]: For [ECDH](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-part-for-ecd) {term}`component keys<OpenPGP Component Key>`, two additional algorithm parameters are integral to the {term}`component key<OpenPGP Component Key>`'s constitutive and immutable properties. Those parameters specify a hash function and a {term}`symmetric<Symmetric Cryptography>` encryption algorithm.
|
||||
|
||||
```{figure} diag/Component_Key.png
|
||||
:name: fig-component-key
|
||||
:alt: Depicts a box with white background and no title. In the box one other box is shown. The inner box has a green frame, with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol, as well as the red-dotted private key symbol in the lower right area. In the top left of the inner box the text reads "Component Key".
|
||||
:alt: Depicts a box with white background and no title. In the box one other box is shown. The inner box has a green frame, with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol, as well as the red-dotted private key symbol in the lower right area. In the top left of the inner box the text reads "Component Key."
|
||||
|
||||
An OpenPGP component key
|
||||
An {term}`OpenPGP component key`
|
||||
```
|
||||
|
||||
Component keys containing private key material also include metadata specifying the password protection scheme. This is another facet of metadata, akin to the aforementioned creation timestamp and additional parameters for certain algorithms. However, this discussion focuses on OpenPGP certificates, in which the component keys contain only the public part of its cryptographic key data. For information on private keys in OpenPGP, see {numref}`private_key_chapter`.
|
||||
{term}`Component keys<OpenPGP Component Key>` containing {term}`private key material` also include {term}`metadata` specifying the password protection scheme. This is another facet of {term}`metadata`, akin to the aforementioned creation timestamp and additional parameters for certain algorithms. However, this discussion focuses on {term}`OpenPGP certificates<OpenPGP Certificate>`, in which the {term}`component keys<OpenPGP Component Key>` contain only the public part of its cryptographic key data. For information on {term}`private keys<Transferable Secret Key>` in OpenPGP, see {numref}`private_key_chapter`.
|
||||
|
||||
(fingerprint)=
|
||||
### Fingerprint
|
||||
|
||||
Each OpenPGP component key possesses an *OpenPGP fingerprint*. This fingerprint is derived from the public key material, the creation timestamp, and, when relevant, the ECDH parameters.
|
||||
Each {term}`OpenPGP component key` possesses an *{term}`OpenPGP fingerprint`*. This {term}`fingerprint<OpenPGP Fingerprint>` is derived from the {term}`public key material<OpenPGP Certificate>`, the {term}`creation timestamp<Creation Time>`, and, when relevant, the ECDH parameters.
|
||||
|
||||
```{figure} diag/Fingerprint.svg
|
||||
:name: fig-fingerprint
|
||||
:alt: Depicts a box with white background and the title "Fingerprint of an OpenPGP component key". Inside, another box with a green frame, the title "Component Key", the text "key creation time" on the lower left and a the green public key symbol on the lower right is shown. Below the component key box a fingerprint in a box with a light-yellow background and a yellow dotted line is depicted. The word "Fingerprint" is shown left of the box with the fingerprint and both are connected with a yellow dotted line.
|
||||
:alt: Depicts a box with white background and the title "Fingerprint of an OpenPGP component key." Inside, another box with a green frame, the title "Component Key", the text "key creation time" on the lower left and a the green public key symbol on the lower right is shown. Below the component key box a fingerprint in a box with a light-yellow background and a yellow dotted line is depicted. The word "Fingerprint" is shown left of the box with the fingerprint and both are connected with a yellow dotted line.
|
||||
|
||||
Every OpenPGP component key is identifiable by a fingerprint.
|
||||
Every {term}`OpenPGP component key` is identifiable by a {term}`fingerprint<OpenPGP Fingerprint>`.
|
||||
```
|
||||
|
||||
The fingerprint of our example OpenPGP component key is `C0A5 8384 A438 E5A1 4F73 7124 26A4 D45D BAEE F4A3 9E6B 30B0 9D55 13F9 78AC CA94`[^keyid].
|
||||
The {term}`fingerprint<OpenPGP Fingerprint>` of our example {term}`OpenPGP component key` is `C0A5 8384 A438 E5A1 4F73 7124 26A4 D45D BAEE F4A3 9E6B 30B0 9D55 13F9 78AC CA94`[^keyid].
|
||||
|
||||
[^keyid]: In OpenPGP version 4, the rightmost 64 bits were sometimes used as a shorter identifier, called "Key ID."
|
||||
For example, an OpenPGP version 4 certificate with the fingerprint `B3D2 7B09 FBA4 1235 2B41 8972 C8B8 6AC4 2455 4239` might be referenced by the 64-bit Key ID `C8B8 6AC4 2455 4239` or formatted as `0xC8B86AC424554239`.
|
||||
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 Key ID," while 64-bit identifiers were referred to as "long Key ID."
|
||||
[^keyid]: In OpenPGP version 4, the rightmost 64 bits were sometimes used as a shorter identifier, called "{term}`Key ID`."
|
||||
For example, an OpenPGP version 4 {term}`certificate<OpenPGP Certificate>` with the {term}`fingerprint<OpenPGP Fingerprint>` `B3D2 7B09 FBA4 1235 2B41 8972 C8B8 6AC4 2455 4239` might be referenced by the 64-bit {term}`Key ID` `C8B8 6AC4 2455 4239` or formatted as `0xC8B86AC424554239`.
|
||||
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 fingerprint of a component key, while not theoretically unique, functions effectively as a unique identifier. The use of a [cryptographic hash algorithm](crypto-hash) in generating fingerprints makes the occurrence of two different component keys with the same 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](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].
|
||||
```
|
||||
|
||||
[^finger-unique]: For both OpenPGP version 6 and version 4, the likelihood of accidental occurrence of duplicate fingerprints is negligible when 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 fingerprint as a given pre-existing 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 fingerprints of OpenPGP version 4 are considered insufficiently strong at protecting against the generation of pairs of key material with the same fingerprint.
|
||||
[^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>`.
|
||||
|
||||
(primary_key)=
|
||||
### Primary key
|
||||
|
||||
The OpenPGP primary key is a component key that serves a distinct, central role in an OpenPGP certificate:
|
||||
The {term}`OpenPGP primary key` is a {term}`component key<OpenPGP Component Key>` that serves a distinct, central role in an {term}`OpenPGP certificate`:
|
||||
|
||||
- Its fingerprint acts as an identifier for the entire OpenPGP certificate.
|
||||
- It facilitates lifecycle operations, such as adding or invalidating subkeys or identities within a certificate.
|
||||
- Its {term}`fingerprint<OpenPGP Fingerprint>` acts as an identifier for the entire {term}`OpenPGP certificate`.
|
||||
- It facilitates lifecycle operations, such as adding or {term}`invalidating<Validation>` {term}`subkeys<OpenPGP Subkey>` or {term}`identities<Identity>` within a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
```{admonition} Terminology
|
||||
:class: note
|
||||
|
||||
In the RFC, the OpenPGP primary key is occasionally referred to as "top-level key." Informally, it has also been termed the "master key."
|
||||
In the {term}`RFC`, the {term}`OpenPGP primary key` is occasionally referred to as "top-level key." Informally, it has also been termed the "{term}`master key<OpenPGP Primary Key>`."
|
||||
```
|
||||
|
||||
(subkeys)=
|
||||
### Subkeys
|
||||
|
||||
Modern OpenPGP certificates typically include several subkeys in addition to the primary key, although these subkeys are optional.
|
||||
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 subkeys have the same structural attributes as the primary key, they fulfill different roles. Subkeys are cryptographically linked with the 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}`binding_subkeys`.
|
||||
|
||||
```{figure} diag/Binding_Subkeys.png
|
||||
:name: fig-subkeys
|
||||
:alt: Diagram depicting three component keys. The primary key is positioned at the top, designated for certification. Below it, connected by arrows, are two subkeys labeled as "for encryption" and "for signing," respectively.
|
||||
|
||||
OpenPGP certificates can contain multiple subkeys.
|
||||
{term}`OpenPGP certificates<OpenPGP Certificate>` can contain multiple {term}`subkeys<OpenPGP Subkey>`.
|
||||
```
|
||||
|
||||
(identity_components)=
|
||||
## Identity components
|
||||
|
||||
Identity components in an OpenPGP certificate are used by the certificate holder to state that they are known by a certain identifier (like a name, or an email address).
|
||||
{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 in OpenPGP certificates
|
||||
|
||||
OpenPGP certificates can contain multiple [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.
|
||||
{term}`OpenPGP certificates<OpenPGP Certificate>` can contain multiple [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13). Each {term}`User ID` associates the {term}`certificate<OpenPGP Certificate>` with an {term}`identity`.
|
||||
|
||||
```{figure} diag/Binding_a_UserID.png
|
||||
:name: fig-user-ids
|
||||
:alt: Depicts a diagram with white background and the title "User IDs". Inside, a public primary component key for certification and a User ID is shown. A green arrow points from component key to User ID and is annotated with a signature.
|
||||
|
||||
Relationship of User ID to primary component key in an OpenPGP certificate
|
||||
Relationship of {term}`User ID` to primary {term}`component key` in an {term}`OpenPGP certificate`
|
||||
```
|
||||
|
||||
A typical User ID identity is a UTF-8-encoded string composed of a name and an email address. By convention, User IDs align with the format described in [RFC2822](https://www.rfc-editor.org/rfc/rfc2822) as a *name-addr*.
|
||||
A typical {term}`User ID` {term}`identity` is a UTF-8-encoded string composed of a name and an email address. By convention, {term}`User IDs<User ID>` align with the format described in [RFC2822](https://www.rfc-editor.org/rfc/rfc2822) as a *name-addr*.
|
||||
|
||||
For further conventions on User IDs, refer to the document [draft-dkg-openpgp-userid-conventions-00](https://datatracker.ietf.org/doc/draft-dkg-openpgp-userid-conventions/), dated 25 August 2023.
|
||||
For further conventions on {term}`User IDs<User ID>`, refer to the document [draft-dkg-openpgp-userid-conventions-00](https://datatracker.ietf.org/doc/draft-dkg-openpgp-userid-conventions/), dated 25 August 2023.
|
||||
|
||||
**Split User IDs**
|
||||
|
||||
One proposed variant for encoding identities in User IDs is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). Although uncommon, there are currently no significant technical barriers to implementing this format[^dkg-split].
|
||||
One proposed variant for encoding {term}`identities<Identity>` in {term}`User IDs<User ID>` is to use ["split User IDs"](https://dkg.fifthhorseman.net/blog/2021-dkg-openpgp-transition.html#split-user-ids). Although uncommon, there are currently no significant technical barriers to implementing this format[^dkg-split].
|
||||
|
||||
[^dkg-split]: Historically, the OpenPGP ecosystem faced challenges in this context. For further details, refer to Daniel Kahn Gillmor's January 2019 article, ["What were Separated User IDs"](https://dkg.fifthhorseman.net/blog/2019-dkg-openpgp-transition.html#what-were-separated-user-ids).
|
||||
|
||||
The rationale for split User IDs lies in the distinction between a name and an email address, which represent two separate facets of an individual's identity. Separating these elements simplifies the process for third parties tasked with certifying that an identity is legitimately connected to a certificate.
|
||||
The rationale for split {term}`User IDs<User ID>` lies in the distinction between a name and an email address, which represent two separate facets of an individual's {term}`identity`. Separating these elements simplifies the process for third parties tasked with certifying that an {term}`identity` is legitimately connected to a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
Consider this scenario: A third party is confident about the email-based identity of an individual (e.g.,`<alice@example.org>`) and is willing to certify it. However, they might not have sufficient knowledge about the person's name-based identity (e.g., `Alice Adams`), so are unwilling to extend the same level of certification. Split User IDs address this dichotomy by allowing distinct certification processes for each type of identity.
|
||||
Consider this scenario: A third party is confident about the email-based {term}`identity` of an individual (e.g.,`<alice@example.org>`) and is willing to certify it. However, they might not have sufficient knowledge about the person's name-based {term}`identity` (e.g., `Alice Adams`), so are unwilling to extend the same level of {term}`certification`. Split {term}`User IDs<User ID>` address this dichotomy by allowing distinct {term}`certification` processes for each type of {term}`identity`.
|
||||
|
||||
(primary_user_id)=
|
||||
### Implications of the Primary User ID
|
||||
|
||||
Within a certificate, a specific User ID is designated as the [Primary User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-primary-user-id).
|
||||
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-10.html#name-primary-user-id).
|
||||
|
||||
Each User ID carries associated preference settings, such as preferred encryption algorithms, which is detailed in {numref}`zooming_in_user_id`). When a certificate is used in the context of a specific identity, then the preferences associated with that identity component are used. When a certificate is used without reference to a specific identity, the preferences associated with the direct key signature, or the 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}`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.
|
||||
|
||||
The primary User ID was historically the main store for preferences that apply to the certificate as a whole. For more on this, see {ref}`primary-metadata`.
|
||||
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`.
|
||||
|
||||
### User attributes in OpenPGP
|
||||
While
|
||||
[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, they are 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 {term}`User IDs<User ID>`, they are less commonly used.
|
||||
|
||||
Currently, the OpenPGP standard prescribes only one format to be stored in user attributes: an [image](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-the-image-attribute-subpack) in JPEG format. Typically, this image represents the key owner, although it is not required.
|
||||
|
||||
## Linking the components
|
||||
|
||||
To form an OpenPGP certificate, individual components are interconnected by the certificate holder using their OpenPGP software. Within OpenPGP, this process is termed "binding," as in "a subkey is bound to the primary key." These bindings are realized using cryptographic signatures. An in-depth discussion of this topic can be found in {ref}`component_signatures_chapter`.
|
||||
To form an {term}`OpenPGP certificate`, individual {term}`components<Component>` are interconnected by the {term}`certificate holder` using their OpenPGP software. Within OpenPGP, this process is termed "binding", as in "a {term}`subkey<OpenPGP Subkey>` is bound to the {term}`primary key<OpenPGP Primary Key>`." These bindings are realized using cryptographic {term}`signatures<OpenPGP Signature Packet>`. An in-depth discussion of this topic can be found in {ref}`component_signatures_chapter`.
|
||||
|
||||
In very abstract terms, the primary key of a certificate acts as a root of trust or "certification authority." It is responsible for:
|
||||
In very abstract terms, the {term}`primary key<OpenPGP Primary Key>` of a {term}`certificate<OpenPGP Certificate>` acts as a root of trust or "{term}`certification authority<Certification Authority>`." It is responsible for:
|
||||
|
||||
- issuing signatures that express the certificate holder's intent to use specific subkeys or identity components;
|
||||
- conducting other lifecycle operations, including setting expiration dates and marking components as invalidated or "revoked."
|
||||
- issuing {term}`signatures<OpenPGP Signature Packet>` that express the {term}`certificate holder`'s intent to use specific {term}`subkeys<OpenPGP Subkey>` or {term}`identity components<Identity Component>`;
|
||||
- conducting other lifecycle operations, including setting {term}`expiration` dates and marking {term}`components<Component>` as {term}`invalidated<Validation>` or "`revoked<Revocation>`."
|
||||
|
||||
By binding components using digital signatures, recipients of an OpenPGP certificate need only validate the authenticity of the primary key to use for their communication partner. Traditionally, this is done by manually verifying the *fingerprint* of the primary key. Once the validity of the primary key is confirmed, the validity of the remaining components can be automatically assessed by the user's OpenPGP software. Generally, components are valid parts of a certificate if there is a statement signed by the certificate's primary key endorsing this validity.
|
||||
By binding {term}`components<Component>` using digital {term}`signatures<OpenPGP Signature Packet>`, recipients of an {term}`OpenPGP certificate` need only {term}`validate<Validation>` the {term}`authenticity<Authentication>` of the {term}`primary key` to use for their communication partner. Traditionally, this is done by manually verifying the *{term}`fingerprint<OpenPGP Fingerprint>`* of the {term}`primary key<OpenPGP Primary Key>`. Once the {term}`validity<Validation>` of the {term}`primary key<OpenPGP Primary Key>` is confirmed, the {term}`validity<Validation>` of the remaining {term}`components<Component>` can be automatically assessed by the user's OpenPGP software. Generally, {term}`components<Component>` are {term}`valid<Validation>` parts of a {term}`certificate<OpenPGP Certificate>` if there is a statement signed by the {term}`certificate<OpenPGP Certificate>`'s {term}`primary key<OpenPGP Primary Key>` endorsing this {term}`validity<Validation>`.
|
||||
|
||||
(metadata_in_certificates)=
|
||||
## Metadata in certificates
|
||||
|
||||
OpenPGP certificates, their component keys, and identities possess metadata that is not stored within the components it pertains to. Instead, this metadata is stored within signature packets, which are integral to the structure of an OpenPGP certificate.
|
||||
{term}`OpenPGP certificates<OpenPGP Certificate>`, their {term}`component keys<Component Key>`, and {term}`identities<Identity>` possess {term}`metadata` that is not stored within the {term}`components<Component>` it pertains to. Instead, this {term}`metadata` is stored within signature packets, which are integral to the structure of an OpenPGP certificate.
|
||||
|
||||
Key attributes, such as capabilities (like *signing* or *encryption*) and expiration times, are examples of metadata not stored in the component key data. How this metadata is stored depends on the component:
|
||||
Key attributes, such as {term}`capabilities<Capability>` (like *signing* or *encryption*) and {term}`expiration times<Expiration Time>`, are examples of {term}`metadata` not stored in the {term}`component key` data. How this {term}`metadata` is stored depends on the {term}`component`:
|
||||
|
||||
- **Primary key metadata** is defined either through a direct key signature on the primary key (preferred in OpenPGP version 6), or by associating the metadata with the [Primary User ID](primary_user_id).
|
||||
- **{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).
|
||||
|
||||
- **Subkey metadata** is defined within the [subkey binding signature](binding_subkeys) that links the subkey to the certificate.
|
||||
- **{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>`.
|
||||
|
||||
- **Identity component metadata** is associated via the [certifying self-signature](bind_ident) that links the identity (usually in the form of a User ID) to the 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>`.
|
||||
|
||||
It is crucial to note that the components of an OpenPGP certificate remain static after their creation. The use of signatures to store metadata allows for subsequent modifications without altering the original components. For instance, a certificate holder can update the expiration time of a component by issuing a new, superseding signature.
|
||||
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>`.
|
||||
|
||||
```{figure} diag/Primary_key_metadata.png
|
||||
:name: fig-primary-metadata
|
||||
:alt: Depicts a direct key signature, associated with a primary component key.
|
||||
|
||||
Metadata can be associated with the primary key using a *direct key signature*.
|
||||
{term}`Metadata` can be associated with the {term}`primary key<OpenPGP Primary Key>` using a *{term}`direct key signature`*.
|
||||
```
|
||||
|
||||
(capabilities_key_flags)=
|
||||
### Defining operational capabilities of component keys with key flags
|
||||
|
||||
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 delineate the operations a key can perform.
|
||||
Each {term}`component key` has a set of ["key flags"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#key-flags) that delineate the operations a key can perform.
|
||||
|
||||
Commonly used key flags include:
|
||||
Commonly used {term}`key flags<Key Flag>` include:
|
||||
|
||||
- **Certification**: enables issuing third-party certifications
|
||||
- **Signing**: allows the key to sign data
|
||||
- **Encryption**: allows the key to encrypt data
|
||||
- **Authentication**: primarily used for SSH authentication[^auth-flag]
|
||||
- **{term}`Certification<Certification Key Flag>`**: enables issuing third-party {term}`certifications<Certification>`
|
||||
- **{term}`Signing<Signing Key Flag>`**: allows the key to sign data
|
||||
- **{term}`Encryption<Encryption Key Flag>`**: allows the key to encrypt data
|
||||
- **{term}`Authentication<Authentication Key Flag>`**: primarily used for SSH authentication[^auth-flag]
|
||||
|
||||
[^auth-flag]: It's important to note that the function of the [authentication](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-authentication-via-digital-) key flag is unrelated to the authentication process used in certifying OpenPGP identities and linking them to certificates. Rather, this flag indicates a mechanism that uses cryptographic signatures to confirm control of private key material with a remote system.
|
||||
[^auth-flag]: It's important to note that the function of the [authentication](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-authentication-via-digital-) {term}`key flag` is unrelated to the {term}`authentication` process used in certifying OpenPGP {term}`identities<Identity>` and linking them to {term}`certificate<OpenPGP Certificate>`. Rather, this flag indicates a mechanism that uses {term}`cryptographic signatures<OpenPGP Signature Packet>` to confirm control of {term}`private key material` with a remote system.
|
||||
|
||||
```{note}
|
||||
Distinct component keys handle specific operations. Only the primary key can be used for certification, although it can have additional capabilities. Subkeys can be used for signing, encryption, and authentication but cannot have the certification capability. A component key can technically have multiple capabilities. It is considered good practice, however, to [use separate keys for each capability](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.5-7).
|
||||
Distinct {term}`component keys<Component Key>` handle specific operations. Only the {term}`primary key<OpenPGP Primary Key>` can be used for {term}`certification`, although it can have additional {term}`capabilities<Capability>`. {term}`Subkeys<OpenPGP Subkey>` can be used for signing, encryption, and authentication but cannot have the {term}`certification` {term}`capability`. A {term}`component key` can technically have multiple {term}`capabilities<Capability>`. It is considered good practice, however, to [use separate keys for each capability](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.1.5-7).
|
||||
|
||||
Notably, in many algorithms, encryption and signing-related functionalities (i.e., certification, signing, authentication) are mutually exclusive, because the algorithms only support one of those two families of operations[^key-flag-sharing].
|
||||
Notably, in many algorithms, encryption and signing-related functionalities (i.e., {term}`certification<Certification Key Flag>`, {term}`signing<Signing Key Flag>`, {term}`authentication<Authentication Key Flag>`) are mutually exclusive, because the algorithms only support one of those two families of operations[^key-flag-sharing].
|
||||
```
|
||||
|
||||
[^key-flag-sharing]: With ECC algorithms, it's impossible to combine encryption functions with those intended for signing. For example, ed25519 is specifically used for signing; cv25519 is designated for encryption.
|
||||
[^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>`.
|
||||
|
||||
### Algorithm preferences and feature signaling
|
||||
|
||||
|
|
@ -231,7 +239,7 @@ OpenPGP incorporates significant ["cryptographic agility"](https://en.wikipedia.
|
|||
|
||||
This agility facilitates the easy adoption of new cryptographic primitives into the standard, allowing for a seamless transition. Users can gradually migrate to new cryptographic mechanisms without disruption.
|
||||
|
||||
However, this approach requires that OpenPGP software determine the cryptographic mechanisms that a set of communication partners can handle and prefer. OpenPGP employs several mechanisms for this purpose, which allow negotiation between sender and recipient. It's important to note that OpenPGP is not an online scheme; thus, this negotiation is effectively one-way. The active party interprets the preferences expressed in the certificate of the passive party.
|
||||
However, this approach requires that OpenPGP software determine the cryptographic mechanisms that a set of communication partners can handle and prefer. OpenPGP employs several mechanisms for this purpose, which allow negotiation between sender and recipient. It's important to note that OpenPGP is not an online scheme; thus, this negotiation is effectively one-way. The active party interprets the preferences expressed in the {term}`certificate<OpenPGP Certificate>` of the passive party.
|
||||
|
||||
Negotiation mechanisms in OpenPGP include:
|
||||
|
||||
|
|
@ -241,55 +249,57 @@ Negotiation mechanisms in OpenPGP include:
|
|||
- [Features subpacket](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#features-subpacket)
|
||||
- [Preferred compression algorithms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#preferred-compression-subpacket)
|
||||
|
||||
Beyond these explicitly expressed preferences, implementations also deduce capabilities of communication partners based on the version of the OpenPGP certificate they possess.
|
||||
Beyond these explicitly expressed preferences, implementations also deduce {term}`capabilities<Capability>` of communication partners based on the version of the {term}`OpenPGP certificate` they possess.
|
||||
|
||||
#### User ID-specific preferences
|
||||
|
||||
As a starting point, a certificate has a set of preferences that apply generally. These are defined either in a direct key signature, or via the primary User ID of the certificate.
|
||||
As a starting point, a {term}`certificate<OpenPGP certificate>` has a set of preferences that apply generally. These are defined either in a {term}`direct key signature`, or via the {term}`primary User ID` of the {term}`certificate<OpenPGP certificate>`.
|
||||
|
||||
Additionally, OpenPGP allows modeling User ID-specific preferences. The idea is that a user may prefer a different suite of algorithms on their private email account compared to their work email account. Such identity-specific preferences can be expressed on the certifying signatures that bind User IDs to a certificate.
|
||||
Additionally, OpenPGP allows modeling {term}`User ID`-specific preferences. The idea is that a user may prefer a different suite of algorithms on their private email account compared to their work email account. Such {term}`identity`-specific preferences can be expressed on the certifying {term}`signatures<OpenPGP Signature Packet>` that bind {term}`User IDs<User ID>` to a {term}`certificate<OpenPGP certificate>`.
|
||||
|
||||
## A typical OpenPGP certificate, revisited
|
||||
|
||||
Following our review of how keys and identity components are linked, let's reexamine the OpenPGP certificate from {numref}`fig-openpgp-certificate-components`. Our focus now extends to all of its binding signatures and the direct key signature that contains metadata for the full certificate:
|
||||
Following our review of how {term}`keys<Component Key>` and {term}`identity components<Identity Component>` are linked, let's reexamine the {term}`OpenPGP certificate` from {numref}`fig-openpgp-certificate-components`. Our focus now extends to all of its binding signatures and the {term}`direct key signature` that contains {term}`metadata` for the full {term}`certificate<OpenPGP certificate>`:
|
||||
|
||||
```{figure} diag/OpenPGP_Certificate.png
|
||||
:name: fig-openpgp-certificate
|
||||
:alt: Depicts an OpenPGP certificate, including a set of components, binding signatures, and a direct key signature on the primary key.
|
||||
|
||||
This shows a typical OpenPGP certificate, including binding signatures for all of its components, and a signature that associates metadata with the primary key.
|
||||
This shows a typical {term}`OpenPGP certificate`, including binding {term}`signatures<OpenPGP Signature Packet>` for all of its {term}`components<Component>`, and a {term}`signature<OpenPGP Signature Packet>` that associates {term}`metadata` with the {term}`primary key<OpenPGP Primary Key>`.
|
||||
```
|
||||
|
||||
(revocations)=
|
||||
## Revocations
|
||||
|
||||
When a certificate owner needs to invalidate certain components of their certificate, or even the entire certificate, they accomplish this through "revocation." Revoking the primary key renders the entire certificate invalid.
|
||||
When a {term}`certificate holder` needs to {term}`invalidate<Validation>` certain {term}`components<Component>` of their {term}`certificate<OpenPGP Certificate>`, or even the entire {term}`certificate<OpenPGP Certificate>`, they accomplish this through "{term}`revocation`." {term}`Revoking<Revocation>` the {term}`primary key<OpenPGP Primary Key>` renders the entire {term}`certificate<OpenPGP Certificate>` {term}`invalid<Validation>`.
|
||||
|
||||
Notably, revocations are not the only means by which components can become invalid. Other factors, such as the passing of a component's expiration time, can also render components invalid.
|
||||
Notably, {term}`revocations<Revocation>` are not the only means by which {term}`components<Component>` can become {term}`invalid<Validation>`. Other factors, such as the passing of a {term}`component`'s {term}`expiration time`, can also render {term}`components<Component>` {term}`invalid<Validation>`.
|
||||
|
||||
For more detailed information on revoking specific components of a certificate, see the section on {ref}`self-revocations`.
|
||||
For more detailed information on {term}`revoking<Revocation>` specific {term}`components<Component>` of a {term}`certificate<OpenPGP Certificate>`, see the section on {ref}`self-revocations`.
|
||||
|
||||
(third_party_identity_certifications)=
|
||||
## Third-party (identity) certifications
|
||||
|
||||
Since its inception, third-party identity certifications have been a cornerstone of the OpenPGP ecosystem. The original PGP designers, starting with Phil Zimmermann, advocated for decentralized trust models over reliance on centralized authorities. This decentralized approach in OpenPGP is known as the ["Web of Trust."](wot)
|
||||
Since its inception, {term}`third-party identity certifications<Third-party Identity Certification>` have been a cornerstone of the OpenPGP ecosystem. The original PGP designers, starting with Phil Zimmermann, advocated for decentralized {term}`trust models<Trust Model>` over reliance on centralized authorities. This decentralized approach in OpenPGP is known as the ["Web of Trust."](wot)
|
||||
|
||||
Third-party certifications are statements by OpenPGP users confirming that a user with a specific identity is the owner of a particular OpenPGP certificate.
|
||||
Third-party {term}`certifications<Certification>` are statements by OpenPGP users confirming that a user with a specific {term}`identity` is the owner of a particular {term}`OpenPGP certificate`.
|
||||
|
||||
For example, Bob's OpenPGP software may issue a certification that Bob has checked that the User ID `Alice Adams <alice@example.org>` and the certificate with the fingerprint `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3` are legitimately linked.
|
||||
For example, Bob's OpenPGP software may issue a {term}`certification` that Bob has checked that the {term}`User ID` `Alice Adams <alice@example.org>` and the {term}`certificate<OpenPGP Certificate>` with the {term}`fingerprint<OpenPGP Fingerprint>` `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3` are legitimately linked.
|
||||
|
||||
Take, for instance, a scenario where Bob's OpenPGP software issues a certification confirming as legitimate the link between the User ID `Alice Adams <alice@example.org>` and the certificate bearing the fingerprint `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`.
|
||||
Take, for instance, a scenario where Bob's OpenPGP software issues a {term}`certification` confirming as legitimate the link between the {term}`User ID` `Alice Adams <alice@example.org>` and the {term}`certificate<OpenPGP Certificate>` bearing the {term}`fingerprint<OpenPGP Fingerprint>` `AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`.
|
||||
|
||||
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 certificate his OpenPGP software associates with Alice matches the one Alice uses. In essence, both users must have a certificate for Alice with an identical fingerprint. In OpenPGP version 6, manual fingerprint comparison by end-users is discouraged, with a replacement verification mechanism still under development. The verification process must occur over a sufficiently secure channel, such as an end-to-end encrypted video call or a face-to-face meeting.
|
||||
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 certifications, see {ref}`third_party_cert`.
|
||||
For more on third-party {term}`certifications<Certification>`, see {ref}`third_party_cert`.
|
||||
|
||||
(cert-flooding)=
|
||||
### Security considerations
|
||||
|
||||
While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks.
|
||||
While a convenience for consumers, indiscriminately accepting and integrating {term}`third-party identity certifications<Third-party Identity Certification>` comes with significant risks.
|
||||
|
||||
Without any restrictions in place, malicious entities can flood a certificate with excessive certifications. Called "certificate flooding," this form of digital vandalism grossly expands the certificate size, making the certificate cumbersome and impractical for users.
|
||||
Without any restrictions in place, malicious entities can flood a {term}`certificate<OpenPGP Certificate>` with excessive {term}`certifications<Certification>`. Called "certificate flooding," this form of digital vandalism grossly expands the {term}`certificate<OpenPGP Certificate>` size, making the {term}`certificate<OpenPGP Certificate>` cumbersome and impractical for users.
|
||||
|
||||
It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation.
|
||||
It also opens the door to potential denial-of-service attacks, rendering the {term}`certificate<OpenPGP Certificate>` non-functional or significantly impeding its operation.
|
||||
|
||||
The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,152 +5,155 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
|
||||
# OpenPGP Signatures
|
||||
|
||||
Signatures are a fundamental mechanism within OpenPGP. They provide the syntax for forming and interpreting comprehensive statements about certificates and their components, as well as for ensuring the integrity and authenticity of data.
|
||||
{term}`Signatures<OpenPGP Signature Packet>` are a fundamental mechanism within OpenPGP. They provide the syntax for forming and interpreting comprehensive statements about {term}`certificates<OpenPGP Certificate>` and their {term}`components<Component>`, as well as for ensuring the integrity and {term}`authenticity<Authentication>` of data.
|
||||
|
||||
Without signatures, keys would remain unassociated with any certificate or owner. Signatures are crucial for binding component keys and identity components into hierarchical certificates and for establishing the authenticity of messages.
|
||||
Without {term}`signatures<OpenPGP Signature Packet>`, {term}`keys<Transferable Secret Key>` would remain unassociated with any {term}`certificate<OpenPGP Certificate>` or {term}`owner<Certificate Holder>`. {term}`Signatures<OpenPGP Signature Packet>` are crucial for binding {term}`component keys<Component Key>` and {term}`identity components<Identity Component>` into hierarchical {term}`certificates<OpenPGP Certificate>` and for establishing the {term}`authenticity<Authentication>` of messages.
|
||||
|
||||
## Terminology
|
||||
|
||||
Within OpenPGP, the term *signature* can have two different meanings:
|
||||
Within OpenPGP, the term *{term}`signature<OpenPGP Signature Packet>`* can have two different meanings:
|
||||
|
||||
- **Cryptographic signature**: a sequence of bytes created by cryptographic keys, calculated according to a signature scheme.
|
||||
- **OpenPGP signature packets**: Defined in the [OpenPGP standard](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2), these packets combine a raw cryptographic signature along with a *type* designation and additional metadata.
|
||||
- **{term}`Cryptographic signature`**: a sequence of bytes created by {term}`cryptographic keys<Cryptographic Key>`, calculated according to a {term}`signature` scheme.
|
||||
- **{term}`OpenPGP signature packets<OpenPGP signature packet>`**: Defined in the [OpenPGP standard](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2), these {term}`packets<Packet>` combine a raw {term}`cryptographic signature` along with a *{term}`type<OpenPGP Signature Type>`* designation and additional {term}`metadata`.
|
||||
|
||||
```{figure} diag/meaning_of_signatures.png
|
||||
:name: fig-meaning-of-signatures
|
||||
:alt: Depicts a box on white background with the title "Meanings of signature in OpenPGP", "signature" in italics. The top half of the box shows a green seal symbol with the word "sig" in it on the left side. The symbol is connected to the text "Cryptographic signature" by a black dotted line. The bottom half of the box shows a diagram. On the left hand side a box with green dotted frame and white background provides the title "Signature type", while inside the box the text reads "Signature over Signature data, Signature metadata". The words "Signature metadata" serve as title for a yellow box at the lower half of the signature type box. The yellow box also contains a cryptographic signature symbol. Right of the signature type box, the text "OpenPGP signature packet" is shown, which is connected to the box by a green dotted line. Below the text a list is shown, which reads "signature type, signature over input data, additional metadata and cryptographic signature". The last item is connected to the cryptographic signature symbol in the yellow box by a black dotted line.
|
||||
|
||||
Two meanings of the term "signature" in OpenPGP
|
||||
Two meanings of the term "{term}`signature<OpenPGP Signature Packet>`" in OpenPGP
|
||||
```
|
||||
|
||||
In this document, "signature" will refer to OpenPGP signature packets.
|
||||
In this document, "{term}`signature<OpenPGP Signature Packet>`" will refer to {term}`OpenPGP signature packets<OpenPGP signature packet>`.
|
||||
|
||||
(signature_types)=
|
||||
## Signature types in OpenPGP
|
||||
|
||||
The OpenPGP standard defines a set of [Signature types](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types), each identified by a numerical *signature type ID*. Signature types define the purpose of a signature packet and how it should be interpreted.
|
||||
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 *{term}`signature type ID`*. {term}`Signature types<OpenPGP Signature Type>` define the purpose of a {term}`signature packet<OpenPGP Signature Packet>` and how it should be interpreted.
|
||||
|
||||
Signature types can be predominantly classified in two ways:
|
||||
{term}`Signature types<OpenPGP Signature Type>` can be predominantly classified in two ways:
|
||||
|
||||
- **Signatures over data**: These signatures are denoted by type IDs `0x00` for binary documents and `0x01` for canonical text documents. The signer uses these signatures to claim ownership, assert creation, or certify the immutability of the document.
|
||||
- **Signatures on components**: These are signatures that are associated with component keys or identity components of a certificate.
|
||||
- **{term}`Signatures over data<Signature Over Data>`**: These signatures are denoted by {term}`type IDs<Type ID>` `0x00` for binary documents and `0x01` for canonical text documents. The {term}`signer` uses these {term}`signatures<OpenPGP Signature Packet>` to claim ownership, assert creation, or certify the immutability of the document.
|
||||
- **{term}`Signatures on components<Signature On Component>`**: These are {term}`signatures<OpenPGP Signature Packet>` that are associated with {term}`component keys<Component Key>` or {term}`identity components<Identity Component>` of a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
Signatures on components are a complex topic, and we discuss them in depth in {ref}`component_signatures_chapter`. They are grouped based on two criteria:
|
||||
{term}`Signatures on components<Signature On Component>` are a complex topic, and we discuss them in depth in {ref}`component_signatures_chapter`. They are grouped based on two criteria:
|
||||
|
||||
- the origin of the signature, distinguishing between a self-signature and a third-party signature
|
||||
- the nature of the statement made by the signature, such as certifying an identity or binding component keys into a certificate
|
||||
- the origin of the {term}`signature<OpenPGP Signature Packet>`, distinguishing between a {term}`self-signature` and a {term}`third-party signature`
|
||||
- the nature of the statement made by the {term}`signature<OpenPGP Signature Packet>`, such as certifying an {term}`identity` or binding {term}`component keys<Component Key>` into a {term}`certificate<OpenPGP Certificate>`
|
||||
|
||||
```{figure} mermaid/sig-types.png
|
||||
:name: fig-signature-types
|
||||
:alt: Depicts a diagram, describing different types of OpenPGP signatures. On the right hand side a long yellow box with the title "Signature Types and Targets" is shown, which contains signature type IDs and their names (in gray boxes) and further yellow boxes, grouping other types of signature type IDs. At the top the signature type ID "0x02 Standalone" is shown. Below, another yellow box groups the "Signature Packet"s "0x50 Third-Party Confirmation" and "0x40 Timestamp". Another box groups types of signatures, that apply to "Data" packets "0x00 Binary Data" and "0x01 Canonical Text". Below, a box groups types of signatures, that apply to "Primary Key + User ID/ Attr. Packet"s. The type IDs "0x10 Generic Certification", "0x11 Persona Certification", "0x12 Casual Certification" and "0x13 Positive Certification" are shown together in one gray box and "0x30 Certification Revocation" in another. Another yellow box groups types of signatures, that apply to "Primary Key" packets "0x1F Direct-Key Signature" and "0x20 Key Revocation". The last box groups types of signatures, that apply to "Primary + Subkey" packets. "0x18 Subkey Binding" and "0x19 Primary Key Binding" are shown together in one gray box, "0x28 Subkey Revocation" in another. On the left hand side of the diagram shows gray boxes identifying different types of signatures, with the most basic being "OpenPGP Signature" on the far left. With arrows it points to further signature types ("Signature on Data", "Signature on Component") and several signature type IDs ("0x02", "0x50" and "0x40"). The signature type "Signature on Data" points to "0x00" and "0x01". The signature type "Signature on Component" points to two more specific signature types, namely "Third-Party" and "Self-Signature". "Third-Party" points at the group of "0x10", "0x11", "0x12" and "0x13", as well as "0x30" and "0x1F". "Self-Signature" points at the group of "0x10", "0x11", "0x12" and "0x13", as well as "0x30", "0x1F", the group of "0x18" and "0x19" and finally "0x28".
|
||||
|
||||
An overview of signature types in OpenPGP
|
||||
An overview of {term}`signature types<OpenPGP Signature Type>` in OpenPGP
|
||||
```
|
||||
|
||||
This chapter will cover the overarching principles applicable to all OpenPGP signature types.
|
||||
This chapter will cover the overarching principles applicable to all {term}`OpenPGP signature types<OpenPGP Signature Type>`.
|
||||
|
||||
For more detail about specific types of signatures, see the chapters on {ref}`signing_data` and {ref}`component_signatures_chapter`, respectively.
|
||||
For more detail about specific {term}`types of signatures<OpenPGP Signature Type>`, see the chapters on {ref}`signing_data` and {ref}`component_signatures_chapter`, respectively.
|
||||
|
||||
## Structure of an OpenPGP signature packet
|
||||
|
||||
As outlined above, an OpenPGP signature is a composite data structure, which combines:
|
||||
As outlined above, an {term}`OpenPGP signature<OpenPGP Signature Packet>` is a composite data structure, which combines:
|
||||
|
||||
- **Signature type ID**: specifies the signature's intended meaning, as detailed above
|
||||
- **Metadata**: varies based, in part, on the signature type ID; mostly encoded as "subpackets" (see {ref}`signature_subpackets`)
|
||||
- **Raw cryptographic signature**
|
||||
- **{term}`Signature type ID`**: specifies the {term}`signature<OpenPGP Signature Packet>`'s intended meaning, as detailed above
|
||||
- **{term}`Metadata`**: varies based, in part, on the {term}`signature type ID`; mostly encoded as "{term}`subpackets<OpenPGP Signature Subpacket>`" (see {ref}`signature_subpackets`)
|
||||
- **Raw {term}`cryptographic signature`**
|
||||
|
||||
```{figure} diag/signature_packet.png
|
||||
:name: fig-signature-packet
|
||||
:alt: Depicts a diagram with the title "A signature packet". On the left hand side a box with green dotted frame and white background provides the title "Signature type", while inside the box the text reads "Signature over Signature data, Signature metadata". The words "Signature metadata" serve as title for a yellow box at the lower half of the signature type box. The yellow box also contains a cryptographic signature symbol. Right of the signature type box, the text "OpenPGP signature packet" is shown, which is connected to the box by a green dotted line. Below the text a list is shown, which reads "signature type, signature over input data, additional metadata and raw cryptographic signature". The last item is connected to the cryptographic signature symbol in the yellow box by a black dotted line.
|
||||
|
||||
Structure of an OpenPGP signature packet
|
||||
Structure of an {term}`OpenPGP signature packet`
|
||||
```
|
||||
|
||||
### Creating an OpenPGP signature packet
|
||||
|
||||
Creating an OpenPGP signature packet involves encoding a statement about a specific set of data within the packet.
|
||||
Creating an {term}`OpenPGP signature packet` involves encoding a statement about a specific set of data within the {term}`packet`.
|
||||
|
||||
The input data of a signature packet includes:
|
||||
The input data of a {term}`signature packet<OpenPGP Signature Packet>` includes:
|
||||
|
||||
- **Packets being signed**: Typically one or more packets, though sometimes none, depending on the context. These are the packets to which the signature statement pertains.
|
||||
- **Data within the signature packet**: This includes information that specifies the intent of the signature.
|
||||
- **{term}`Packets<Packet>` being signed**: Typically one or more {term}`packets<Packet>`, though sometimes none, depending on the context. These are the {term}`packets<Packet>` to which the signature statement pertains.
|
||||
- **Data within the {term}`signature packet`**: This includes information that specifies the intent of the {term}`signature<OpenPGP Signature Packet>`.
|
||||
|
||||
The input data is determined by the signature type and consists of the exact content that the signature statement addresses.
|
||||
The input data is determined by the {term}`signature type<OpenPGP Signature Type>` and consists of the exact content that the signature statement addresses.
|
||||
|
||||
The signature packet consists of two parts:
|
||||
The {term}`signature packet<OpenPGP Signature Packet>` consists of two parts:
|
||||
|
||||
1. **Statement definition**: This part of the packet defines the meaning or intent of the signature.
|
||||
2. **Cryptographic digital signature**: This is the formal endorsement by the signer, created as follows:
|
||||
- A hash digest is calculated from the input data.
|
||||
- The signature is then calculated for this hash digest.
|
||||
1. **Statement definition**: This part of the {term}`packet` defines the meaning or intent of the {term}`signature<OpenPGP Signature Packet>`.
|
||||
2. **{term}`Cryptographic signature`**: This is the formal endorsement by the {term}`signer`, created as follows:
|
||||
- A {term}`hash digest` is calculated from the input data.
|
||||
- The {term}`cryptographic signature` is then calculated for this {term}`hash digest`.
|
||||
|
||||
```{figure} diag/Signature_Creation.png
|
||||
:name: fig-signature-creation
|
||||
:alt: Depicts a complex diagram with white background and the title "Signature creation". On the top left side a box with black frame and white background reads "Input Data packets, One or more packets". Below it the symbol of a signature packet is shown (however, instead of the green signature symbol, only a circle with white background and dotted frame is shown). Both are connected (via green dotted arrows) to a green, right pointing arrow symbol with green dotted frame and the title "Hash mechanism". Text above the green arrow symbol reads "A hash digest is calculated from the input data packets and the signature metadata". The "Hash mechanism" arrow points at a box with white background and green frame, which reads "hash digest". At the top right corner of the diagram the symbol for a component key with both public and private key and the title "Signer private key" is shown. Both hash digest and component key symbol point to a large green arrow symbol, with green dotted frame, at the lower right corner of the diagram, using green dotted arrow lines. The large arrow symbol has the title "Signing mechanism" and text overlaid across it reads "A cryptographic signature is calculated over the hash digest, using the private key material of the signer.". It points at a cryptographic signature symbol at the bottom of the diagram. The cryptographic signature symbol is connected (via a green dotted arrow line) to the circle with white background and dotted green frame in the signature packet symbol.
|
||||
|
||||
Creating a signature in OpenPGP
|
||||
Creating a {term}`signature<OpenPGP Signature Packet>` in OpenPGP
|
||||
```
|
||||
|
||||
(sig-verify)=
|
||||
### Verifying an OpenPGP signature packet
|
||||
|
||||
Verifying an OpenPGP signature packet is similar to its creation, with some crucial differences that facilitate the verification by entities other than the signer.
|
||||
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`.
|
||||
|
||||
The main differences:
|
||||
|
||||
- **Access to public key**: Unlike the creation process, which is exclusive to the signer, verification can be performed by anyone who has access to the public key of the signer.
|
||||
- **Use of signature verification mechanism**:
|
||||
After calculating the hash digest from the input data, a signature verification mechanism is employed. This mechanism uses the hash digest, the cryptographic signature from the signature packet, and the public key of the signer. Its purpose is to ascertain the cryptographic validity of the signature.
|
||||
- **Access to {term}`public key<OpenPGP Certificate>`**: Unlike the creation process, which is exclusive to the {term}`signer`, {term}`verification` can be performed by anyone who has access to the {term}`public key<OpenPGP Certificate>` of the {term}`signer`.
|
||||
- **Use of {term}`signature verification` mechanism**:
|
||||
After calculating the {term}`hash digest` from the input data, a {term}`signature verification` mechanism is employed. This mechanism uses the {term}`hash digest`, the {term}`cryptographic signature` from the {term}`signature packet<OpenPGP Signature Packet>`, and the {term}`public key<OpenPGP Certificate>` of the {term}`signer`. Its purpose is to ascertain the cryptographic {term}`validity<Validation>` of the {term}`signature<OpenPGP Signature Packet>`.
|
||||
|
||||
```{figure} diag/Signature_Verification.png
|
||||
:name: fig-signature-verification
|
||||
:alt: Depicts a complex diagram with white background and the title "Signature verification". On the top left side a box with black frame and white background reads "Input Data packets, One or more packets". Below it the symbol of a signature packet is shown. Both are connected (via green dotted arrows) to a green, right pointing arrow symbol with green dotted frame and the title "Hash mechanism". Text above the green arrow symbol reads "A hash digest is calculated from the input data packates and the signature metadata". The "Hash mechanism" arrow points at a box with white background and green frame, which reads "hash digest". At the top right corner of the diagram the symbol for a component key with only public key and the title "Signer public key" is shown. Hash digest, component key symbol and the cryptographic signature symbol in the signature packet point to a large green arrow symbol, with green dotted frame, at the lower right corner of the diagram, using green dotted arrow lines. The large arrow symbol has the title "Signature verification mechanism" and text overlaid across it reads "A cryptographic signature is verified against the hash digest, using the public key of the signer.". It points at a success and fail symbol at the bottom of the diagram.
|
||||
|
||||
Verifying a signature in OpenPGP
|
||||
Verifying a {term}`signature<OpenPGP Signature Packet>` in OpenPGP
|
||||
```
|
||||
|
||||
(signature_subpackets)=
|
||||
## Signature subpackets
|
||||
|
||||
In the OpenPGP protocol, signature subpackets enhance the expressiveness of a signature beyond what is conveyed by just the bare cryptographic signature and the signature type ID. These subpackets, introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440), are essential for embedding additional metadata within signature packets.
|
||||
In the OpenPGP protocol, {term}`signature subpackets<OpenPGP Signature Subpacket>` enhance the expressiveness of a {term}`signature<OpenPGP Signature Packet>` beyond what is conveyed by just the bare {term}`cryptographic signature` and the {term}`signature type ID`. These {term}`subpackets<OpenPGP Signature Subpacket>`, introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440), are essential for embedding additional {term}`metadata` within {term}`signature packets<OpenPGP Signature Packet>`.
|
||||
|
||||
Signature subpackets serve as sub-elements within signature packets, providing extra context and meaning to a signature.
|
||||
They are formatted as key-value pairs, where the keys are defined as [subpacket type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-subpacket-types-r) by the RFC. The RFC also provides the format and interpretation of the values.
|
||||
{term}`Signature subpackets<OpenPGP Signature subpacket>` serve as sub-elements within {term}`signature packets<OpenPGP Signature Packet>`, providing extra context and meaning to a {term}`signature<OpenPGP Signature Packet>`.
|
||||
They are formatted as key-value pairs, where the keys are defined as [subpacket type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-subpacket-types-r) by the {term}`RFC`. The {term}`RFC` also provides the format and interpretation of the values.
|
||||
|
||||
### Examples of signature subpackets
|
||||
- The [*issuer fingerprint*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#issuer-fingerprint-subpacket) subpacket encodes the fingerprint of the component key that issued the signature.
|
||||
- The [*key flags*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) subpacket defines the capabilities that are assigned to a component key within a certificate.
|
||||
- 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)=
|
||||
### Hashed and unhashed signature subpackets
|
||||
|
||||
Signature subpackets within OpenPGP can reside in one of two distinct areas of a signature packet, each serving a different purpose.
|
||||
{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.
|
||||
|
||||
- **Hashed area**: Hashed subpackets are included in the hash digest of the signature and are thus covered by its cryptographic signature. They reliably express the signer's intent.
|
||||
- **Unhashed area**: Unhashed subpackets, conversely, are not included in the hash digest for the signature. They are thus not protected against tampering and can be used to retroactively add, change, or remove metadata in a signature packet without affecting its validity. They are primarily used for advisory purposes or in scenarios where the integrity of the subpacket content can be self-authenticated. An example is the issuer fingerprint subpacket, which can be validated through successful signature verification using the referenced issuer key.
|
||||
- **{term}`Hashed area`**: {term}`Hashed subpackets<Hashed Subpacket>` are included in the {term}`hash digest` of the {term}`signature<OpenPGP Signature Packet>` and are thus covered by its {term}`cryptographic signature`. They reliably express the {term}`signer`'s intent.
|
||||
- **{term}`Unhashed area`**: {term}`Unhashed subpackets<Unhashed Subpacket>`, conversely, are not included in the {term}`hash digest` for the {term}`signature<OpenPGP Signature Packet>`. They are thus not protected against tampering and can be used to retroactively add, change, or remove metadata in a {term}`signature packet<OpenPGP Signature Packet>` without affecting its {term}`validity<Validation>`. They are primarily used for advisory purposes or in scenarios where the integrity of the {term}`subpacket` content can be self-authenticated. An example is the {term}`issuer fingerprint subpacket`, which can be {term}`validated<Validation>` through successful {term}`signature verification` using the referenced {term}`issuer key`.
|
||||
|
||||
The majority of signature subpackets are stored in the hashed area.
|
||||
The majority of {term}`signature subpackets<OpenPGP Signature Subpacket>` are stored in the {term}`hashed area`.
|
||||
|
||||
For detailed information and specifications, refer to [Hashed vs. Unhashed Subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hashed-vs-unhashed-subpacke) in the OpenPGP RFC.
|
||||
For detailed information and specifications, refer to [Hashed vs. Unhashed Subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hashed-vs-unhashed-subpacke) in the OpenPGP {term}`RFC`.
|
||||
|
||||
(criticality_of_subpackets)=
|
||||
### Criticality of subpackets
|
||||
|
||||
In the OpenPGP protocol, each signature subpacket can be marked with a *criticality flag*. This flag plays a pivotal role in the interpretation and validation of the signature. When set, it instructs any receiving implementation encountering an unrecognized subpacket type to treat this as a significant error and to invalidate the signature.
|
||||
In the OpenPGP protocol, each {term}`signature subpacket<OpenPGP Signature Subpacket>` can be marked with a *{term}`criticality flag`*. This flag plays a pivotal role in the interpretation and {term}`validation` of the {term}`signature<OpenPGP Signature Packet>`. When set, it instructs any receiving {term}`implementation<OpenPGP Implementation>` encountering an unrecognized {term}`subpacket type<OpenPGP Signature Subpacket Type>` to treat this as a significant error and to {term}`invalidate<Validation>` the {term}`signature<OpenPGP Signature Packet>`.
|
||||
|
||||
This mechanism accounts for different OpenPGP implementations that may support only certain subsets of the standard. Moreover, it anticipates the evolution of the standard, including the addition of new subpacket types.
|
||||
This mechanism accounts for different {term}`OpenPGP implementations<OpenPGP Implementation>` that may support only certain subsets of the standard. Moreover, it anticipates the evolution of the standard, including the addition of new {term}`subpacket types<OpenPGP Signature Subpacket Type>`.
|
||||
|
||||
Consider a scenario where an implementation does not recognize a subpacket indicating signature expiration. Without understanding this concept, the implementation might erroneously accept an already expired signature. By marking the expiration date subpacket as critical, the creator of the signature ensures that any recipient who cannot process this subpacket will reject the signature as invalid.
|
||||
Consider a scenario where an {term}`implementation<OpenPGP Implementation>` does not recognize a {term}`subpacket<OpenPGP Signature Subpacket>` indicating {term}`signature<OpenPGP Signature Packet>` {term}`expiration`. Without understanding this concept, the {term}`implementation<OpenPGP Implementation>` might erroneously accept an already {term}`expired<Expiration>` {term}`signature<OpenPGP Signature Packet>`. By marking the {term}`expiration date subpacket` as {term}`critical<Criticality Flag>`, the creator of the {term}`signature<OpenPGP Signature Packet>` ensures that any recipient who cannot process this {term}`subpacket<OpenPGP Signature Subpacket>` will reject the {term}`signature<OpenPGP Signature Packet>` as {term}`invalid<Validation>`.
|
||||
|
||||
For specific guidelines on which subpackets should be marked as critical, refer to the RFC sections [5.2.3.11](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-creation-time) to [5.2.3.36](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-intended-recipient-fingerpr).
|
||||
For specific guidelines on which {term}`subpackets<OpenPGP Signature Subpacket>` should be marked as {term}`critical<Criticality Flag>`, refer to the {term}`RFC` sections [5.2.3.11](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-creation-time) to [5.2.3.36](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-intended-recipient-fingerpr).
|
||||
|
||||
## Advanced topics
|
||||
|
||||
(notation_signature_subpackets)=
|
||||
### Notation signature subpackets
|
||||
|
||||
[Notation signature subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#notation-data) can be used to effectively extend the otherwise limited set of signature subpacket types in OpenPGP with user-defined notations. Issuers can use these notations to add name-value pairs to an OpenPGP signature.
|
||||
[Notation signature subpackets](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#notation-data) can be used to effectively extend the otherwise limited set of {term}`signature subpacket types<OpenPGP Signature Subpacket Type>` in OpenPGP with user-defined {term}`notations<Notation>`. {term}`Issuers<Issuer>` can use these {term}`notations<Notation>` to add name-value pairs to an {term}`OpenPGP signature<OpenPGP Signature Packet>`.
|
||||
|
||||
Notation names – strings encoded in UTF-8 – may reside in the "user namespace." This namespace is characterized by a notation *tag*, followed by a DNS domain name, both in UTF-8 format.
|
||||
{term}`Notation` names - strings encoded in UTF-8 - may reside in the "user namespace." This namespace is characterized by a {term}`notation tag`, followed by a DNS domain name, both in UTF-8 format.
|
||||
|
||||
Notations, as described earlier, allow for user-defined extensions to the OpenPGP signature subpacket types. A practical and popular application of this functionality is seen in Keyoxide, a decentralized identity verification service. Keyoxide uses notations in the `ariadne.id` namespace. For the details of this implementation, refer to the [Keyoxide documentation](https://docs.keyoxide.org/wiki/ariadne-identity/).
|
||||
{term}`Notations<Notation>`, as described earlier, allow for user-defined extensions to the {term}`OpenPGP signature subpacket types<OpenPGP Signature Subpacket Type>`. A practical and popular application of this functionality is seen in Keyoxide, a decentralized {term}`identity verification` service. Keyoxide uses {term}`notations<Notation>` in the `ariadne.id` namespace. For the details of this {term}`implementation<OpenPGP Implementation>`, refer to the [Keyoxide documentation](https://docs.keyoxide.org/wiki/ariadne-identity/).
|
||||
|
||||
### "Negotiating" signature hash algorithm based on recipients preference subpackets
|
||||
|
||||
|
|
|
|||
|
|
@ -8,39 +8,370 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
```{glossary}
|
||||
:sorted:
|
||||
|
||||
Authentication
|
||||
Checking the validity of a claim (e.g. an identity claim). Making sure that a claim is "authentic."
|
||||
Asymmetric Cryptography
|
||||
Asymmetric cryptography is used in OpenPGP. For a more detailed discussion see [](public_key_asymmetric_cryptography).
|
||||
|
||||
Certification
|
||||
"Third party Signature" on a certificate, making a statement about that certificate, or an identity in the certificate
|
||||
Authentication
|
||||
The process of {term}`validiting<Validation>` an {term}`identity claim`.
|
||||
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).
|
||||
|
||||
Authentication Tag
|
||||
See {term}`Message Authentication Code`.
|
||||
|
||||
Authenticity
|
||||
See {term}`Authentication`.
|
||||
|
||||
CA
|
||||
[Certificate authority](https://en.wikipedia.org/wiki/Certificate_authority) or certification authority. An entity that handles digital certificates, especially by signing or issuing them.
|
||||
See {term}`Certification Authority`.
|
||||
|
||||
Delegation
|
||||
See {term}`Trust signature`
|
||||
Capability
|
||||
The operations an {term}`OpenPGP Component Key` can perform. See [](capabilities_key_flags).
|
||||
|
||||
Certificate
|
||||
See {term}`OpenPGP Certificate`
|
||||
|
||||
Certificate Authority
|
||||
See {term}`Certification Authority`
|
||||
|
||||
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.
|
||||
|
||||
Certificate Holder
|
||||
A person or other entity, that holds an {term}`Transferable Secret Key` and thus is able to modify the accompanying {term}`OpenPGP Certificate`.
|
||||
|
||||
Certification
|
||||
"Third party Signature" on a certificate, making a statement about that {term}`certificate<OpenPGP Certificate>`, or an {term}`identity` in the {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
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).
|
||||
|
||||
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).
|
||||
|
||||
Component
|
||||
An element in an {term}`OpenPGP Certificate`, that represents a {term}`component key` or {term}`identity component`.
|
||||
|
||||
Component Key
|
||||
See {term}`OpenPGP Component Key`.
|
||||
|
||||
Creation Time
|
||||
The point in time at which e.g. an {term}`OpenPGP Certificate`, or one of its {term}`component<Component>` is created.
|
||||
|
||||
Creator
|
||||
See {term}`Issuer`.
|
||||
|
||||
Criticality Flag
|
||||
A flag on {term}`Subpacket`s, that defines their criticality, which is used for validation. See [](criticality_of_subpackets).
|
||||
|
||||
Cryptographic Key
|
||||
A {term}`symmetric<Symmetric Cryptography>` or {term}`asymmetric<Asymmetric Cryptography>` cryptographic key is used for signing and encryption operations. See [](03-cryptography).
|
||||
|
||||
Cryptographic Signature
|
||||
A raw cryptographic signature is a sequence of bytes created by a {term}`Cryptographic Key`.
|
||||
|
||||
CTB
|
||||
See {term}`Cipher Type Byte`.
|
||||
|
||||
Delegation
|
||||
See {term}`Trust signature`
|
||||
|
||||
Direct Key Signature
|
||||
A {term}`Signature` that sets preferences and advertises features applicable to an entire {term}`Certificate`. See [](direct_key_signature).
|
||||
|
||||
Encryption Key Flag
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for encrypting data. See [](capabilities_key_flags).
|
||||
|
||||
Expiration
|
||||
A mechanism by which a {term}`Component` is invalidated due to the {term}`Expiration Time` of its binding signature being older than the {term}`Reference Time` by which it is validated.
|
||||
|
||||
Expiration Date Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the {term}`Expiration Time` for an {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Expiration Time
|
||||
The time of expiry of an {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Fingerprint
|
||||
See {term}`OpenPGP Fingerprint`.
|
||||
|
||||
Hash Digest
|
||||
Output of a cryptographic hash function for a string of data of any length. See [](crypto-hash).
|
||||
|
||||
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).
|
||||
|
||||
Hashed Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket` residing in the {term}`Hashed Area` of an {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Hybrid Cryptosystem
|
||||
A cryptographic system that employs both {term}`Asymmetric Cryptography` and {term}`Symmetric Cryptography`. See [](hybrid_cryptosystems).
|
||||
|
||||
Identity
|
||||
An identity of a {term}`Certificate Holder`. It is represented by an {term}`Identity Component`, which may be certified using {term}`third-party identity certifications<Third-party Identity Certification>`, or by a {term}`Notation`.
|
||||
|
||||
Identity Claim
|
||||
A {term}`Certificate Holder` may use {term}`Identity Components<Identity Component>` or {term}`Notations<Notation>` to state a claim about their {term}`Identity`.
|
||||
|
||||
Identity Component
|
||||
Part of an {term}`OpenPGP Certificate`, that is used to associate data about the {term}`Certificate Holder` with it. See [](identity_components) for further details.
|
||||
|
||||
Identity Verification
|
||||
A process by which the {term}`Identity Claim` of a {term}`Certificate Holder` is verified. See also {term}`Signature Verification`.
|
||||
|
||||
Issuer
|
||||
An entity, that created an {term}`OpenPGP Signature Packet` using an {term}`Transferable Secret Key`.
|
||||
|
||||
Issuer Fingerprint Subpacket
|
||||
A {term}`Subpacket` specifying the {term}`Fingerprint` of an {term}`Issuer Key`.
|
||||
|
||||
Issuer Key
|
||||
The {term}`OpenPGP Component Key` of an {term}`Issuer`, used to create an {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Key
|
||||
See {term}`OpenPGP Key`
|
||||
In OpenPGP, and cryptography more generally, the term "key" holds different meanings.
|
||||
|
||||
First, it can apply to different [cryptographic primitives](cryptography_chapter):
|
||||
|
||||
- asymmetric public key
|
||||
- asymmetric private key
|
||||
- {term}`Symmetric Secret Key`
|
||||
|
||||
Additionally, in OpenPGP, asymmetric cryptographic keys are used on [three different layers](layers_of_keys_in_openpgp) of abstraction:
|
||||
|
||||
- cryptographic key
|
||||
- OpenPGP component key
|
||||
- {term}`OpenPGP key` (which in turn refers to either an {term}`OpenPGP Certificate` or a {term}`Transferable Secret Key`
|
||||
|
||||
OpenPGP Key
|
||||
Used either for an OpenPGP Certificate (containing public key material and metadata), or for an See {term}`OpenPGP Private Key`
|
||||
Key Flag
|
||||
A preference encoded in an {term}`OpenPGP Signature Subpacket`, that defines the {term}`Capability` a {term}`OpenPGP Component Key` has. See [](signature_subpackets).
|
||||
|
||||
OpenPGP Private Key
|
||||
The combination of an {term}`OpenPGP Certificate` and the associated private key material
|
||||
Key ID
|
||||
The high-order (leftmost) 64 bits of an {term}`OpenPGP Fingerprint`.
|
||||
Historically, this term refers to the low-order (rightmost) 64 bits of an {term}`OpenPGP Fingerprint`.
|
||||
|
||||
Key Material
|
||||
May refer to {term}`Public Key Material` or {term}`Private Key Material`.
|
||||
|
||||
Key Holder
|
||||
See {term}`Certificate Holder`.
|
||||
|
||||
Key Owner
|
||||
See {term}`Certificate Holder`.
|
||||
|
||||
MAC
|
||||
See {term}`Message Authentication Code`.
|
||||
|
||||
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).
|
||||
|
||||
Metadata
|
||||
Data related to preferences of an {term}`OpenPGP Certificate` or its {term}`Certificate Holder`, that can be found in {term}`signature` {term}`packets<Packet>`. See [](metadata_in_certificates).
|
||||
|
||||
Notation
|
||||
A mechanism for a {term}`Certificate Holder` to provide user-defined data using a {term}`Notation Signature Subpacket`.
|
||||
|
||||
Notation Signature Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket` which is used to add user-defined data to a {term}`Certificate`. See [](notation_signature_subpackets).
|
||||
|
||||
Notation Tag
|
||||
Part of a {term}`Notation` name.
|
||||
|
||||
OpenPGP Certificate
|
||||
An OpenPGP certificate contains public key material, identity claims and third party certifications (but no private key material)
|
||||
|
||||
OpenPGP Component Key
|
||||
An {term}`OpenPGP Primary Key` or {term}`OpenPGP Subkey`. For an in-depth discussion see [](component_keys).
|
||||
|
||||
OpenPGP Fingerprint
|
||||
A fingerprint, that is unique for each {term}`OpenPGP Component Key`. See [](fingerprint).
|
||||
|
||||
OpenPGP Implementation
|
||||
A piece of software implementing the OpenPGP protocol (to some extend).
|
||||
|
||||
OpenPGP Key
|
||||
Used either for an {term}`OpenPGP Certificate` (containing public key material and metadata), or for an {term}`OpenPGP Private Key`. See [](/04-certificates) for an in-depth discussion.
|
||||
|
||||
OpenPGP Public Key
|
||||
See {term}`OpenPGP Certificate`.
|
||||
|
||||
OpenPGP Private Key
|
||||
See {term}`Transferable Secret Key`.
|
||||
|
||||
OpenPGP Primary Key
|
||||
The primary key of an {term}`OpenPGP Certificate`. For a more detailed discussion, see [](primary_key).
|
||||
|
||||
OpenPGP Signature
|
||||
See {term}`OpenPGP Signature Packet`.
|
||||
|
||||
OpenPGP Signature Packet
|
||||
A {term}`packet` that contains a raw {term}`cryptographic signature`, a {term}`Signature Type ID` and additional {term}`metadata`. See [](/06-signatures). Basic concepts are introduced in [](/06-signatures) and more detailed use-cases are explained in [](/07-signing_data) and [](/08-signing_components).
|
||||
|
||||
OpenPGP Signature Subpacket
|
||||
A data structure in a {term}`Signature Packet`, that describes {term}`metadata` and preferences. See [](signature_subpackets).
|
||||
|
||||
OpenPGP Signature Subpacket Type
|
||||
An {term}`OpenPGP Signature Subpacket` type.
|
||||
|
||||
OpenPGP Signature Type
|
||||
The type of an {term}`OpenPGP Signature Packet` is defined by its {term}`Signature Type ID`. See [](signature_types).
|
||||
|
||||
OpenPGP Subkey
|
||||
A subkey of an {term}`OpenPGP Certificate`. For a more detailed discussion, see [](subkeys).
|
||||
|
||||
Owner
|
||||
See {term}`Certificate Holder`.
|
||||
|
||||
Packet
|
||||
An element in an {term}`OpenPGP Certificate`, which represents {term}`components<Component>` or {term}`signatures<OpenPGP Signature Packet>`.
|
||||
|
||||
Packet Header
|
||||
A section of variable length at the beginning of a {term}`Packet`, which encodes for example the {term}`Packet Type ID`. See the relevant [section in the RFC](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-headers), which explains this section in more detail.
|
||||
|
||||
Packet Tag
|
||||
This historical term was defined in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-4.2) and is 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).
|
||||
|
||||
Packet Type ID
|
||||
A numerical value encoded in the first octet of a {term}`Packet Header`, defining a {term}`Packet`'s type.
|
||||
|
||||
Primary Component Key
|
||||
See {term}`OpenPGP Primary Key`.
|
||||
|
||||
Primary Key
|
||||
See {term}`OpenPGP Primary Key`.
|
||||
|
||||
Primary User ID
|
||||
A {term}`User ID` which carries the default preferences for {term}`identity components<Identity Component>` without preferences. See [](primary_user_id).
|
||||
|
||||
Private Key
|
||||
See {term}`Transferable Secret Key`.
|
||||
|
||||
Private Key Material
|
||||
A raw cryptographic private key.
|
||||
|
||||
Public Key
|
||||
See {term}`OpenPGP Public Key`.
|
||||
|
||||
Public Key Algorithm
|
||||
An {term}`asymmetric cryptographic<Asymmetric Cryptography>` algorithm. See [](public_key_asymmetric_cryptography).
|
||||
|
||||
Public Key Cryptography
|
||||
See {term}`Asymmetric Cryptography`.
|
||||
|
||||
Public Key Material
|
||||
See {term}`OpenPGP Certificate`.
|
||||
|
||||
Reference Time
|
||||
A point in time at which an {term}`OpenPGP Certificate` is evaluated.
|
||||
|
||||
Revocation
|
||||
Mechanism to invalidate a {term}`component` or an entire {term}`OpenPGP Certificate`. See [](revocations).
|
||||
|
||||
Revocation certificate
|
||||
A type of signature that invalidates a previous statement made via a signature
|
||||
A type of {term}`signature` that invalidates a previous statement made via a {term}`signature`
|
||||
|
||||
RFC
|
||||
This document, unless noted otherwise, refers to the [OpenPGP version 6 specification](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/) when referring to *RFC*.
|
||||
|
||||
Self-signature
|
||||
An {term}`OpenPGP Signature Packet` by the {term}`Certificate Holder` on a {term}`Component` of their own {term}`Certificate`.
|
||||
|
||||
Session Key
|
||||
A unique shared secret used in encryption in a {term}`Hybrid Cryptosystem`. See {ref}`encryption_chapter` and {ref}`decryption_chapter`.
|
||||
|
||||
Signature
|
||||
See {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Signature On Component
|
||||
{term}`Cryptographic signature` associated with {term}`Component Keys<Component Key>` or {term}`Identity Components<Identity Component>`. See [](/08-signing_components).
|
||||
|
||||
Signature Over Data
|
||||
{term}`Cryptographic signature` over binary documents or canonical text documents. See [](/07-signing_data).
|
||||
|
||||
Signature Packet
|
||||
See {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Signature Subpacket
|
||||
See {term}`OpenPGP Signature Subpacket`.
|
||||
|
||||
Signature Subpacket Type
|
||||
See {term}`OpenPGP Signature Subpacket Type`.
|
||||
|
||||
Signature Type
|
||||
See {term}`OpenPGP Signature Type`.
|
||||
|
||||
Signature Type ID
|
||||
A numerical identifier for a {term}`Signature Type`.
|
||||
|
||||
Signature Verification
|
||||
In cryptography the mechanism of verification relates to a process in which a claim (i.e., a {term}`signature`) is tested (i.e., using the relevant {term}`components<Component>` of a {term}`certificate`).
|
||||
|
||||
Signer
|
||||
A {term}`Certificate Holder`, that is able to create {term}`self-signatures<Self-signature>` and {term}`third-party signatures<Third-party Signature>`.
|
||||
|
||||
Signing Key Flag
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for signing data. See [](capabilities_key_flags).
|
||||
|
||||
Subkey
|
||||
See {term}`OpenPGP Subkey`.
|
||||
|
||||
Subpacket
|
||||
See {term}`OpenPGP Signature Subpacket`.
|
||||
|
||||
Subpacket Type
|
||||
See {term}`OpenPGP Signature Subpacket Type`.
|
||||
|
||||
Symmetric Cryptography
|
||||
Symmetric cryptography is used in OpenPGP. For a more detailed discussion see [](symmetric_key_cryptography).
|
||||
|
||||
Symmetric Secret Key
|
||||
The {term}`Private Key Material` used in {term}`Symmetric Cryptography`.
|
||||
|
||||
Third-party Identity Certification
|
||||
{term}`Certification` by third-parties to confirm ownership of an {term}`OpenPGP Certificate` by a {term}`Certificate Holder`. See [](third_party_identity_certifications).
|
||||
|
||||
Third-party Signature
|
||||
A {term}`Signature` by a third-party on a {term}`Component` of a {term}`Certificate`.
|
||||
|
||||
Transferable Secret Key
|
||||
A Transferable Secret Key (TSK) is the combination of an {term}`OpenPGP Certificate` and the associated {term}`private key material`. Also often referred to as an "OpenPGP private key". It is discussed in detail in [](/05-private).
|
||||
|
||||
Trust Model
|
||||
A model by which trust between {term}`identities<Identity>` associated with different {term}`OpenPGP Certificates<OpenPGP Certificate>` is created. See [](third_party_identity_certifications).
|
||||
|
||||
Trust signature
|
||||
a specific type of certification for a certificate, which marks that key as a "trusted introducer" (i.e. the party that creates the trust signature signals that they will trust certifications that the "trusted introducer" makes on certificates)
|
||||
|
||||
TSK
|
||||
See {term}`Transferable Secret Key`.
|
||||
|
||||
tsig
|
||||
See {term}`Trust signature`
|
||||
```
|
||||
|
||||
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).
|
||||
|
||||
Unhashed Subpacket
|
||||
A {term}`Signature Subpacket` residing in the {term}`Unhashed Area` of a {term}`Signature Packet`.
|
||||
|
||||
User ID
|
||||
An {term}`Identity Component`, which describes an {term}`Identity` of a {term}`Certificate Holder`. See [](user_ids_in_openpgp_certificates).
|
||||
|
||||
Validation
|
||||
A mechanism by which the [operational needs of a use-case are met](https://en.wikipedia.org/wiki/Verification_and_validation#Validation).
|
||||
In OpenPGP terminology this may refer to processes such as ensuring, that an {term}`OpenPGP Signature Packet` has been created after a {term}`Transferable Secret Key`'s {term}`Creation Time`, but before its {term}`Expiration Time`.
|
||||
|
||||
Validity
|
||||
See {term}`Validation`.
|
||||
|
||||
Verification
|
||||
A mechanism by which the [compliance with design specifications are met](https://en.wikipedia.org/wiki/Verification_and_validation#Verification).
|
||||
In OpenPGP terminology this may refer to e.g. {term}`Signature Verification` or {term}`Identity Verification`.
|
||||
```
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue