X-Git-Url: https://codewiz.org/gitweb?a=blobdiff_plain;f=website%2Ftrust-models.mdwn;h=37928ebd52f4f8759f53fefc9cd00bbbc971adc3;hb=072e05ac7a9872edc3a3e18e103bbba2706254bf;hp=60aa680a3f4d0153a5bdb5ad06a40ecba00e5b45;hpb=99b3c2c4aa1e145ed14e22612abb3473016ac307;p=monkeysphere.git diff --git a/website/trust-models.mdwn b/website/trust-models.mdwn index 60aa680..37928eb 100644 --- a/website/trust-models.mdwn +++ b/website/trust-models.mdwn @@ -1,4 +1,75 @@ -[[meta title +[[!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 @@ -11,11 +82,122 @@ These colon-delimited records say (in order): * `tru`: this is a trust database record * ``: 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: this is just the old trust model plus trust signatures. I'll go into trust signatures later. - * `1220401097`: seconds since the epoch that i created the trust db. + * `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 are needed for full User ID+Key validity + * `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 (not sure exactly how this is used) + * `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.