+++ /dev/null
-[[!meta title="OpenPGP Trust Models"]]
-
-# 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](http://tools.ietf.org/html/rfc4880#section-5.12)". 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](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) 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](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) 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](http://tools.ietf.org/html/rfc4880#section-5.2.3.14)
-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](http://gnupg.org/), and reading [gpg's
- `DETAILS`](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/DETAILS?root=GnuPG&view=markup).
- Unfortunately, `DETAILS` seems to often conflate the ideas of trust
- and validity, which can make it confusing to read.
-
- * [RFC 4880](http://tools.ietf.org/html/rfc4880) 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](http://tools.ietf.org/html/rfc4880#section-5.2.3.13).
- How your particular OpenPGP client chooses to calculate User ID
- validity is therefore implementation-specific.
projects / monkeysphere.git / blobdiff