OpenPGP Trust Models

Monkeysphere relies on GPG's definition of the OpenPGP web of trust, so it's important to understand how GPG calculates User ID validity for a key.

The basic question that a trust model tries to answer is: For a given User ID on a specific key, given some set of valid certifications (signatures), and some explicit statements about whose certifications you think are trustworthy (ownertrust), should we consider this User ID to be legitimately attached to this key (a "valid" User ID)?

It's worth noting that there are two integral parts in this calculation:

the certifications themselves -- this is the objective part: the correctness of these signatures can be calculated with a known algorithm which everyone knows and agrees on, based on the public keys involved.
the ownertrust -- this is the subjective part: Who do you trust to identify other entities on the network? And how much do you trust them to make these identifications correctly? Everyone could (and should!) answer this question differently, based on their values and their relationships to the entities in question.

I might trust my sister's certifications because we've talked about what sorts of certifications we feel comfortable making, and i agree with her choices ("full" or "complete" ownertrust). You might not know her at all, and have no reason to treat her certifications as valid (no ownertrust).

I might decide that the local municipality's procedures for obtaining identity documents are a joke, and not trust their certifications at all (no ownertrust), while you might feel that their certifications are helpful as corroboration, but not to be trusted on their own ("marginal" or "partial" ownertrust). (Note: I wish my municipality actually made cryptographic certifications of identity, regardless of the ownertrust i'd put in them!)

What does "validity" mean anyway?

You see the term "validity" a lot in this context, but it has several subtly different meanings:

First of all, someone might speak of the validity of a key itself, which could mean two things:

The key is cryptographically well-formed, not revoked, not expired, and has reasonable self-signatures on its User ID packets.
It is also sometimes used to mean something like "the maximum validity of any associated User ID or User Attribute". This definition is often not very useful; because if you care about User IDs at all, you usually care about a specific User ID.

So the more useful definition of validity is actually User ID validity:

Given that:
- the key itself is valid, in the first narrow sense used above, and
- given the UserID's set of cryptographically-correct certifications, and
- given your personal subjective declarations about who you trust to make certifications (and how much you trust them to do this),
is this User ID bound to its key with an acceptable trust path?

Examining your GPG trust database

You can see your trust database parameters like this:

gpg --with-colons --list-key bogusgarbagehere 2>/dev/null | head -n1

for me, it looks like this:

tru::1:1220401097:1220465006:3:1:5

These colon-delimited records say (in order):

tru: this is a trust database record
<empty>: the trust database is not stale (might be 'o' for old, or 't' for "built with different trust model and not yet updated")
1: uses new "PGP" trust model (0 would be the "Classic trust model") -- see below
1220401097: seconds since the epoch that I created the trust db.
1220465006: seconds after the epoch that the trustdb will need to be rechecked (usually due to the closest pending expiration, etc)
3: Either 3 certifications from keys with marginal ownertrust ...
1: Or 1 certification from a key with full ownertrust is needed for full User ID+Key validity
5: max_cert_depth (i'm not sure exactly how this is used, though the name is certainly suggestive)

Classic trust model

As far as i can tell, the basic trust model is just the 3 and 1 from the above description:

how many certifications from keys with marginal ownertrust are needed to grant full validity to a User ID on a key?
how many certifications from keys with full ownertrust are needed to grant full validity for a User ID on a key?

If either of these are satisfied, the User ID is considered to be legitimately attached to its key (it is "fully" valid).

If there are no certifications from anyone you trust, the User ID is considered to have unknown validity, which basically means "not valid".

If there are some certifications from people who you trust, but not enough to satisfy either condition above, the User ID has "marginal validity".

PGP trust model (Classic trust model + trust signatures)

Note that so far, your ability to express ownertrust is relatively clumsy. You can say "i trust the certifications made by this keyholder completely", or "a little bit", or "not at all". And these decisions about ownertrust are an entirely private matter. You have no formal way to declare it, or to automatically interpret and act on others' declarations. There is also no way to limit the scope of this ownertrust (e.g. "I trust my co-worker to properly identify anyone in our company, but would prefer not to trust him to identify my bank").

Trust signatures are a way to address these concerns. With a trust signature, I can announce to the world that i think my sister's certifications are legitimate. She is a "trusted introducer". If i use "trust level 1", this is equivalent to my ownertrust declaration, except that i can now make it formally public by publishing the trust signature to any keyserver.

If you trust my judgement in this area (the spec calls my role in this scenario a "!meta introducer"), then you should be able to automatically accept certifications made by my sister by creating a level 2 trust signature on my key. You can choose whether to publish this trust signature or not, but as long as your gpg instance knows about it, my sister's certifications will be treated as legitimate.

Combining trust signatures with regular expressions allows you to scope your trust declarations. So, for example, if you work at ExampleCo, you might indicate in a standard level 1 trust signature on your co-worker's key that you trust them to identify any User ID within the example.com domain.

Problems and Questions with Chained Trust

How do partial/marginal ownertrust and chained trust connections interact? That is, if:

A privately grants "marginal" ownertrust for B, and
B issues a "marginal" trust signature at level 1 for C, and
C certifies D's User ID and key,

Then what should A see as the calculated validity for D's User ID? Surely nothing more than "marginal", but if A marginally trusts two other certifications on D, should that add up to full validity?

What if the chain goes out more levels than above? Does "marginal" get more attenuated somehow as a chain of marginals gets deeper? And how exactly does max_cert_depth play into all this?

What about regex-scoped trust signatures of level > 1? Does the scoping apply to all dependent trust signatures? Has this sort of thing been tested?

"ultimate" ownertrust in GnuPG

Note that for a key under your sole control, which you expect to use to certify other people's User IDs, you would typically give that key "ultimate" ownertrust, which for the purposes of the calculations described here is very similar to "full".

The difference appears to be this: If a key with "full" ownertrust but with no valid User IDs makes a certification, that certification will not be considered. But if the certifying key has "ultimate" ownertrust, then its certifications are considered.

So "full" ownertrust on a key is only meaningful as long as there is a trust path to some User ID on that key already. "ultimate" ownertrust is meaningful anyway, because presumably you control that key.

Other references

Much of this was gathered from experimenting with GnuPG, and reading gpg's DETAILS. Unfortunately, DETAILS seems to often conflate the ideas of trust and validity, which can make it confusing to read.
RFC 4880 is the canonical modern OpenPGP reference. If you want to understand the pieces to this puzzle in detail, this is the place to go. However, it doesn't describe the trust model calculations discussed here directly, but only points at them obliquely, through the definition of trust signatures. How your particular OpenPGP client chooses to calculate User ID validity is therefore implementation-specific.