vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-22 23:52:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

edit ch8 3rd party signatures

Browse source
This commit is contained in:
Tammi L. Coles 2023-11-23 16:44:21 +01:00
parent a8b17f8fe4
commit 94abcc34f7
1 changed files with 31 additions and 49 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

80
book/source/08-signing_components.md
View file

@ -40,7 +40,7 @@ No [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-
### Third-party signatures
Third-party signatures are pivotal in OpenPGP for decentralized authentication, forming the basis of the *Web of Trust*. They encode authentication-related statements about certificates and linked identities, establishing trustworthiness and verification.
Third-party signatures are pivotal in OpenPGP for decentralized authentication, forming the basis of the Web of Trust. They encode authentication-related statements about certificates and linked identities, establishing trustworthiness and verification.
Third-party signatures are used to make specific statements:
@ -62,7 +62,7 @@ The meaning of an OpenPGP signature depends significantly on its issuer. Self-si
In another instance:
- *When issued as a self-signature*, a [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) sets preferences and advertises features applicable to the entire certificate.
- *When issued by a third party*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket, a similar direct key signature delegates trust to the signed certificate. This designates the signed certificate as a trust root within the issuer's *Web of Trust*.
- *When issued by a third party*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket, a similar direct key signature delegates trust to the signed certificate. This designates the signed certificate as a trust root within the issuer's Web of Trust.
## Self-signatures in certificate formation and management
@ -200,76 +200,60 @@ A revocation signature lacking a *reason for revocation* subpacket is interprete
```
(third_party_cert)=
## Third-party signatures: Authentication statements
## Authentication and delegation in third-party signatures
Signatures on components by third parties mainly encode authentication of identities and delegations of trust decisions.
Third party signatures can be inspected and reasoned about manually by humans. More powerfully, though, they can also be used as machine-readable artifacts, by OpenPGP software, which can reason about the authenticity of certificates on behalf of its users, based on trust roots that the user has specified.
Third-party signatures in OpenPGP primarily encode authentication statements for identities and delegate trust decisions. These signatures can be manually inspected or processed as machine-readable artifacts by OpenPGP software, which evaluates the authenticity of certificates based on user-specified trust roots.
### Certifying identity components
By issuing a certifying signature on an identity, the signer expresses that he has verified that the identity and the certificate are meaningfully linked. The signer vouches for the connection between the certificate and the identity.
When a signer issues a certifying signature on an identity, it indicates a verified link between the identity and the certificate.That is, the signer vouches for the connection.
If Alice is certain that the identity `Bob Baker <bob@example.com>` controls the certificate `0xB0B`, she can create a certification signature that binds Bob's User ID and Bob's certificate. Bob will usually distribute this certifying signature from Alice as part of his certificate.
For example, Alice can certify Bob's User ID `Bob Baker <bob@example.com>` with his certificate `0xB0B`, by creating a certification signature that binds Bob's User ID and Bob's certificate. Bob then distributes Alice's certifying signature as part of his certificate.
Effectively, this is a way for Alice to broadcast the statement "I, Alice, have checked that `Bob Baker <bob@example.com>` controls the certificate `0xB0B`." Other users may or may not decide to rely on this statement by Alice.
Other users may or may not decide to rely on Alice's statement.
### Delegating authentication: Trust signatures
### Trust signatures: delegating authentication
The OpenPGP standard specifies primitives to delegate authentication decisions to certificates. The standard uses the (somewhat confusing) term "trust" for this mechanism. Delegating authentication decisions to a certificate, using a [*trust signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#trust-signature-subpacket) subpacket, makes the target certificate a "trusted introducer."
OpenPGP uses [*trust signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#trust-signature-subpacket) subpackets to delegate authentication decisions, transforming the recipient certificate into a "trusted introducer" (or a trust root) for the user. This includes specifying trust depth (or level) for transitive delegations and quantifying trust with numerical values, indicating the extent of reliance on the introducer's certifications.
A "trusted introducer" acts as a trust root for the user.
Trust signature subpackets are applicable in:
[*Trust signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#trust-signature-subpacket) subpackets can be used in two types of signatures:
- identity certification signatures (type ID `0x10` - `0x13`)
- [direct key signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) (type ID `0x1F`)
- On an identity certification signature (type ID `0x10` - `0x13`), or on a
- [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) (type ID `0x1F`)
#### Trust depth/level
#### Trust depth (or "level")
The trust depth (or level) in OpenPGP signifies the extent of transitive delegation within the authentication process. It determines how far the trust can be extended from the original trusted introducer to subsequent intermediaries. Essentially, a certificate with a designated trust depth acts as a "meta-introducer," facilitating authentication decisions across multiple levels in the network.
OpenPGP's delegation mechanism allows specifying transitive delegation of trust: delegating authentication decisions across more than one hop. The standard refers to certificates as a "meta-introducer," when a "trust signature" subpacket defines it as a trusted introducer with a depth (or "level") of two or more.
For example, a trust depth of 1 means there is direct trust in the certifications made by the trusted introducer. In this case, the user's OpenPGP software will accept certifications made directly by the introducer for authenticating identities.
A trust signature subpacket with means that the target certificate may delegate to a second, intermediate, introducer, which in turn has issued a certification signature for an identity.
However, when the trust depth is set higher, it implies a chain of trust extending beyond the initial introducer. The user's software will recognize and accept certifications made not only by the primary introducer but also by other intermediaries whom the primary introducer trusts.
**Examples**
When Alice delegates trust decisions to Trent, designating Trent as a trusted introducer with a *trust depth* of 1, then Alice's OpenPGP implementation will only accept direct certifications by Trent. For example, Trent may have certified that Bob's certificate with the fingerprint `0xB0B` is legitimately connected to Bob's User ID `Bob <bob@example.org>`. If Alice tries to communicate with Bob using his identity `Bob <bob@example.org>`, then Alice's OpenPGP software can automatically determine that the certificate `0xB0B` is appropriate to use.
However, Alice's OpenPGP software wouldn't accept a series of delegations from Trent via Tristan to a certification of Carol's identity (let's imagine that Trent has designated Tristan a trusted introducer). For Alice's OpenPGP software to accept such a path, she needs to designate Trent as a trusted introducer with the `level` set to 2 or more.
This allows for a more extensive network of trusted certifications, enabling a broader and more interconnected Web of Trust.
```{admonition} VISUAL
:class: warning
add diagrams?
Heiko, I found the example confusing. So more text is here AND I recommend adding a visual to illustrate it, using your former example.
```
#### Trust amount
#### Trust amounts
A trust signature can quantify the degree to which the issuer wants to rely on a delegation. This "trust amount" has a numerical value between 0 and 255.
The trust amount, with a numerical value ranging from 0 to 255, quantifies the degree of trust in a delegation.
A trust amount of 120 indicates "complete trust," which means that a certification by that trusted introducer is considered sufficient to consider authentications by that introducer as sufficient.
**Examples**
If Alice designates Trent as a trusted introducer at a trust amount of 120, then Alice's OpenPGP software will consider Bob's identity fully authenticated if Trent has certified it.
However, if Alice only assigns a trust amount of 60 (which indicates "partial trust") to Trent, then her software would not consider Bob's identity fully authenticated. Now let's imagine that Alice additionally assigns a trust amount of 60 to Tristan (a second, independent introducer), and Tristan also certified Bob's identity. In this case, Alice's OpenPGP software will consider Bob's identity fully authenticated, based on the combination of both delegations, and the certifications the two trusted introducers issued.
A higher value indicates greater trust, such as 120 for complete trust, while lower values suggest partial trust. This quantification aids OpenPGP software in determining the authentication level based on combined trust from multiple trusted introducers.
```{admonition} VISUAL
:class: warning
add diagrams?
add diagrams? @heiko -- yes, using the examples that I removed
```
#### Limiting the scope of delegations with regular expressions
#### Limiting delegation scope
When using *trust signature* subpackets, a delegation can be limited to identities that match a [*regular expression*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#regex-subpacket), for example, to limit the email address in a User ID to a specific domain name.
When using *trust signature* subpackets, a delegation can be limited to identities that match a [*regular expression*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#regex-subpacket).
With this mechanism, it is possible to delegate authentication decisions only for User IDs that match the email domain of an organization.
**Example**
For example, Alice could delegate trust decisions only for email addresses in the domain `bob.com` to Bob, if she considers Bob to be a reasonable source of identity certifications for that domain.
With this mechanism, for example, it is possible to delegate authentication decisions only for User IDs that match the email domain of an organization.
```{admonition} VISUAL
:class: warning
@ -278,19 +262,17 @@ add diagrams?
```
(wot)=
### Decentralized automated trust decisions; or, the "Web of Trust"
### Web of Trust: Decentralized trust decisions
The OpenPGP, the "Web of Trust" is a trust model that performs authentication decisions on a set of certifications and delegations[^strong-set].
The Web of Trust in OpenPGP is a trust model that facilitates authentication decisions through a network of certifications and delegations.[^strong-set] It is characterized by a so-called [strong set](https://en.wikipedia.org/wiki/Web_of_trust#Strong_set), which refers to a group of certificates that are robustly interconnected via third-party certifications.
[^strong-set]: In the context of the Web of Trust, the so-called [strong set](https://en.wikipedia.org/wiki/Web_of_trust#Strong_set) refers to a set of certificates that are strongly linked amongst each other via third-party certifications.
In this model, users independently delegate authentication decisions, choosing whom to trust among various certificate issuers. This delegation is based on the certificates and third-party signatures available to them, with their OpenPGP software applying the Web of Trust mechanism to discern the reliability of each certificate for an identity.
The OpenPGP "Web of Trust" model assumes that every user makes their own choice about who they delegate authentication decisions to. Based on the available certificates and third-party signatures, the user's OpenPGP software uses the Web of Trust mechanism to determine which certificates are considered reliable for an identity.
The OpenPGP RFC doesn't specify exactly how Web of Trust calculations are performed. It only defines the data formats on which these calculations can be performed. See external resources in {numref}`wot-resources`.
The OpenPGP RFC doesn't specify how exactly Web of Trust calculations are performed. It only defines the data formats that these calculations can be performed on. See external resources in {numref}`wot-resources`.
### Revoking third-party signatures
### Revoking third-party signatures: Undoing previous statements
The issuer of a third-party signature can undo such a signature by issuing a [*certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`).
To reverse a previously issued third-party signature, the issuer can generate a [*certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`). The revocation must be issued by the same key that created the original signature or, in deprecated practice, by a designated Revocation Key.
## Advanced topics