mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-23 08:02:05 +01:00
ch8: some more text about delegating trust and WoT
This commit is contained in:
parent
6812b29d23
commit
42eb52e95c
2 changed files with 46 additions and 19 deletions
|
@ -233,24 +233,49 @@ Effectively, this is a way for Alice to broadcast the statement "I, Alice, have
|
||||||
|
|
||||||
### Delegating authentication: Trust signatures
|
### Delegating authentication: Trust signatures
|
||||||
|
|
||||||
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."
|
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."
|
||||||
|
|
||||||
A "trusted introducer" acts as a trust root for the user.
|
A "trusted introducer" acts as a trust root for the user.
|
||||||
|
|
||||||
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 "level" of two or more.
|
|
||||||
|
|
||||||
A "level 2" trust signature suboacket means that the target certificate may delegate to a second, intermediate, introducer, which in turn has issued a certification signature for an identity.
|
|
||||||
|
|
||||||
[*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:
|
[*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:
|
||||||
|
|
||||||
- On an identity certification signature (type ID `0x10` - `0x13`), or on a
|
- 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`)
|
- [*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 (or "level")
|
||||||
|
|
||||||
```{admonition} TODO
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
```{admonition} VISUAL
|
||||||
:class: warning
|
:class: warning
|
||||||
|
|
||||||
Write about amount
|
add diagrams?
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Trust amount
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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 additionall 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.
|
||||||
|
|
||||||
|
```{admonition} VISUAL
|
||||||
|
:class: warning
|
||||||
|
|
||||||
|
add diagrams?
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Limiting the scope of delegations with regular expressions
|
#### Limiting the scope of delegations with regular expressions
|
||||||
|
@ -259,25 +284,27 @@ When using *trust signature* subpackets, a delegation can be limited to identiti
|
||||||
|
|
||||||
With this mechanism, it is possible to delegate authentication decisions only for User IDs that match the email domain of an organization.
|
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.
|
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.
|
||||||
|
|
||||||
|
```{admonition} VISUAL
|
||||||
|
:class: warning
|
||||||
|
|
||||||
|
add diagrams?
|
||||||
|
```
|
||||||
|
|
||||||
### Decentralized automated trust decisions; or, the "Web of Trust"
|
### Decentralized automated trust decisions; or, the "Web of Trust"
|
||||||
|
|
||||||
```{admonition} TODO
|
The OpenPGP, the "Web of Trust" is a trust model that performs authentication decisions on a set of certifications and delegations.
|
||||||
:class: warning
|
|
||||||
|
|
||||||
More WoT.
|
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 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: Undoing previous statements
|
### Revoking third-party signatures: Undoing previous statements
|
||||||
|
|
||||||
```{admonition} TODO
|
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`).
|
||||||
:class: warning
|
|
||||||
|
|
||||||
write
|
|
||||||
```
|
|
||||||
|
|
||||||
- [*Certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`)
|
|
||||||
|
|
||||||
## Advanced topics
|
## Advanced topics
|
||||||
|
|
||||||
|
|
|
@ -9,7 +9,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
||||||
|
|
||||||
[RFC4880](https://www.rfc-editor.org/rfc/rfc4880.html) OpenPGP Message Format [2007], specifies OpenPGP version 4
|
[RFC4880](https://www.rfc-editor.org/rfc/rfc4880.html) OpenPGP Message Format [2007], specifies OpenPGP version 4
|
||||||
|
|
||||||
|
(wot-resources)=
|
||||||
## Web of Trust
|
## Web of Trust
|
||||||
|
|
||||||
[PGP Web of Trust: Core Concepts Behind Trusted Communication](https://www.linux.com/training-tutorials/pgp-web-trust-core-concepts-behind-trusted-communication/),
|
[PGP Web of Trust: Core Concepts Behind Trusted Communication](https://www.linux.com/training-tutorials/pgp-web-trust-core-concepts-behind-trusted-communication/),
|
||||||
|
|
Loading…
Reference in a new issue