mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-27 01:52:06 +01:00
59 lines
2.7 KiB
Markdown
59 lines
2.7 KiB
Markdown
# Signatures as "statments"
|
|
|
|
```
|
|
- Purpose of a signature
|
|
- Meaning of different signature types, nuances of subpackets
|
|
- Can we have a "catalogue" of statements a user might want to make, mapping these to archetypical signatures?
|
|
- Revocation; Hard vs. Soft
|
|
```
|
|
|
|
## Certifications (third party signatures on keys)
|
|
|
|
A certification is a machine-readable statement about a (public) key, made by a third party.
|
|
In OpenPGP, certifications are implemented as
|
|
[Signature Packets](https://datatracker.ietf.org/doc/html/rfc4880#section-5.2).
|
|
|
|
More specifically, certifications in OpenPGP are usually modelled as "third party binding signatures".
|
|
|
|
Typically, certifications in OpenPGP work like this: Alice checks that a key `0x1234...` belongs to Bob, who uses the
|
|
email address `bob@example.org`. After making sure that the key `0x1234...` and the digital identity `bob@example.org`
|
|
are meaningfully linked, she creates a certification stating that the key and the identity are linked.
|
|
|
|
Such a certification can serve two purposes:
|
|
|
|
1) Alice's OpenPGP software can now reason about Bob's key, and thus show that `0x1234...` is a good key to use for
|
|
interacting with `bob@example.org`.
|
|
2) Other parties can observe Alice's certification and derive some amount of confidence in Bob's key from it.
|
|
For example, Carol might not easily be able to check if `0x1234...` is Bob's key, but she might consider Alice's
|
|
certification for Bob's key sufficient evidence.
|
|
|
|
Carol may decide to systematically rely on Alice's certifications. Then we say that Carol uses Alice as a
|
|
"trusted introducer". That is, Carol *delegates* part of her authentication decisions to Alice.
|
|
|
|
|
|
### Regular certifications
|
|
|
|
Are a cryptographic statement that binds a User ID and a Key (via its fingerprint) together.
|
|
|
|
Have a SignatureType in `GenericCertification, PersonaCertification, CasualCertification, PositiveCertification`.
|
|
|
|
### Trust signatures (using a key as "trusted introducer")
|
|
|
|
A "trust signature" has two additional parameters: a `depth` and a `level`.
|
|
|
|
#### Alternative model: direct key signatures for pure delegation
|
|
|
|
This is useful for using 0xB as a trusted introducer without asserting that 0xB is Bob
|
|
(when a tsig is on a User ID, it is necessarily *also* a vouch about the binding).
|
|
|
|
The logical place to store a tsig that is not also a vouch about a binding is a direct key signature
|
|
(however, GnuPG does probably not respect such tsigs).
|
|
|
|
The [OpenPGP Web of Trust](https://sequoia-pgp.gitlab.io/sequoia-wot/) spec allows such direct key signatures.
|
|
|
|
SignatureType is `DirectKey`
|
|
|
|
In Sequoia, roughly:
|
|
```
|
|
SignatureBuilder::new(SignatureType::GenericCertification).set_trust_signature(..).sign_direct_key(&mut your_signer, &signee_cert.primary_key())
|
|
```
|