mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-27 01:52:06 +01:00
ch8: third-party signatures
This commit is contained in:
parent
61d664f0b0
commit
6812b29d23
1 changed files with 54 additions and 13 deletions
|
@ -217,7 +217,59 @@ A revocation signature that has no *reason for revocation* subpacket is interpre
|
||||||
```
|
```
|
||||||
|
|
||||||
(third_party_cert)=
|
(third_party_cert)=
|
||||||
## Third-party certifications: Encoding authentication statements
|
## Third-party signatures: Authentication statements
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### 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."
|
||||||
|
|
||||||
|
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:
|
||||||
|
|
||||||
|
- 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`)
|
||||||
|
|
||||||
|
|
||||||
|
```{admonition} TODO
|
||||||
|
:class: warning
|
||||||
|
|
||||||
|
Write about amount
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Limiting the scope of delegations with regular expressions
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
With this mechanism, it is possible to delegate authentication decisions only for User IDs that match the email domain of an organization.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Decentralized automated trust decisions; or, the "Web of Trust"
|
||||||
|
|
||||||
|
```{admonition} TODO
|
||||||
|
:class: warning
|
||||||
|
|
||||||
|
More WoT.
|
||||||
|
```
|
||||||
|
|
||||||
|
### Revoking third-party signatures: Undoing previous statements
|
||||||
|
|
||||||
```{admonition} TODO
|
```{admonition} TODO
|
||||||
:class: warning
|
:class: warning
|
||||||
|
@ -225,18 +277,7 @@ A revocation signature that has no *reason for revocation* subpacket is interpre
|
||||||
write
|
write
|
||||||
```
|
```
|
||||||
|
|
||||||
### Certifying identities
|
- [*Certification revocation signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-certification-revocation-si) (type ID `0x30`)
|
||||||
|
|
||||||
Certifications over User IDs can also be used to certify certificates of third-parties.
|
|
||||||
If Alice is certain that `Bob Baker <bob@example.com>` controls the key `0xB0B`, she can create a User ID certification signature for that identity and send it to Bob.
|
|
||||||
Bob can then add this signature to his certificate.
|
|
||||||
|
|
||||||
TODO: More WoT.
|
|
||||||
|
|
||||||
### Delegating authentication: trust signatures
|
|
||||||
|
|
||||||
### Revocations: Undoing previous statements
|
|
||||||
|
|
||||||
|
|
||||||
## Advanced topics
|
## Advanced topics
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue