website/trust-models.mdwn

   1 [[meta title="OpenPGP Trust Models"]]
   2
   3 # OpenPGP Trust Models #
   4
   5 Monkeysphere relies on GPG's definition of the OpenPGP web of trust,
   6 so it's important to understand how GPG calculates User ID validity
   7 for a key.
   8
   9 The basic question that a trust model tries to answer is: For a given
  10 User ID on a specific key, given some set of valid certifications
  11 (signatures), and some explicit statements about whose certifications
  12 you think are trustworthy (ownertrust), should we consider this User
  13 ID to be legitimately attached to this key (a "valid" User ID)?
  14
  15 It's worth noting that there are two integral parts in this
  16 calculation:
  17
  18  *  the certifications themselves -- this is the objective part: the
  19     correctness of these signatures can be calculated with a known
  20     algorithm which everyone knows and agrees on, based on the public
  21     keys involved.
  22
  23  *  the ownertrust -- this is the subjective part: Who do you trust to
  24     identify other entities on the network?  And *how much* do you
  25     trust them to make these identifications correctly?  Everyone could
  26     (and should!) answer this question differently, based on their
  27     values and their relationships to the entities in question.
  28
  29     I might trust my sister's certifications because we've talked about
  30     what sorts of certifications we feel comfortable making, and i
  31     agree with her choices ("full" or "complete" ownertrust).  You
  32     might not know her at all, and have no reason to treat her
  33     certifications as valid (no ownertrust).
  34
  35     I might decide that the local municipality's procedures for
  36     obtaining identity documents are a joke, and not trust their
  37     certifications at all (no ownertrust), while you might feel that
  38     their certifications are helpful as corroboration, but not to be
  39     trusted on their own ("marginal" or "partial" ownertrust).  (Note:
  40     I wish my municipality actually made cryptographic certifications
  41     of identity, regardless of the ownertrust i'd put in them!)
  42
  43 ## What does "validity" mean anyway? ##
  44
  45 You see the term "validity" a lot in this context, but it has several
  46 subtly different meanings:
  47
  48 First of all, someone might speak of the validity of a key itself,
  49 which could mean two things:
  50
  51  *  The key is cryptographically well-formed, not revoked, not expired,
  52     and has reasonable self-signatures on its User ID packets.
  53
  54  *  It is *also* sometimes used to mean something like "the maximum
  55     validity of any associated User ID or [User
  56     Attribute](http://tools.ietf.org/html/rfc4880#section-5.12)".  This
  57     definition is often not very useful; because if you care about User
  58     IDs at all, you usually care about a *specific* User ID.
  59
  60 So the more useful definition of validity is actually *User ID
  61 validity*:
  62
  63  *  Given that:
  64
  65     * the key itself is valid, in the first narrow sense used above, and
  66     * given the UserID's set of cryptographically-correct certifications, and
  67     * given your personal subjective declarations about who you trust to make certifications (and *how much* you trust them to do this),
  68
  69     is this User ID bound to its key with an acceptable trust path?
  70
  71 ## Examining your GPG trust database ##
  72
  73 You can see your trust database parameters like this:
  74
  75         gpg --with-colons --list-key bogusgarbagehere 2>/dev/null | head -n1
  76
  77 for me, it looks like this:
  78
  79         tru::1:1220401097:1220465006:3:1:5
  80
  81 These colon-delimited records say (in order):
  82
  83  * `tru`: this is a trust database record
  84  * `<empty>`: the trust database is not stale (might be 'o' for old, or 't' for "built with different trust model and not yet updated")
  85  * `1`: uses new "PGP" trust model (0 would be the "Classic trust model") -- see below
  86  * `1220401097`: seconds since the epoch that I created the trust db.
  87  * `1220465006`: seconds after the epoch that the trustdb will need to be rechecked (usually due to the closest pending expiration, etc)
  88  * `3`: Either 3 certifications from keys with marginal ownertrust ...
  89  * `1`: Or 1 certification from a key with full ownertrust is needed for full User ID+Key validity
  90  * `5`: `max_cert_depth` (i'm not sure exactly how this is used, though the name is certainly suggestive)
  91
  92
  93 ## Classic trust model ##
  94
  95 As far as i can tell, the basic trust model is just the `3` and `1`
  96 from the above description:
  97
  98  *  how many certifications from keys with marginal ownertrust are
  99     needed to grant full validity to a User ID on a key?
 100
 101  *  how many certifications from keys with full ownertrust are needed
 102     to grant full validity for a User ID on a key?
 103
 104 If either of these are satisfied, the User ID is considered to be
 105 legitimately attached to its key (it is "fully" valid).
 106
 107 If there are no certifications from anyone you trust, the User ID is
 108 considered to have unknown validity, which basically means "not
 109 valid".
 110
 111 If there are *some* certifications from people who you trust, but not
 112 enough to satisfy either condition above, the User ID has "marginal
 113 validity".
 114
 115 ## PGP trust model (Classic trust model + trust signatures) ##
 116
 117 Note that so far, your ability to express ownertrust is relatively
 118 clumsy.  You can say "i trust the certifications made by this
 119 keyholder completely", or "a little bit", or "not at all".  And these
 120 decisions about ownertrust are an entirely private matter.  You have
 121 no formal way to declare it, or to automatically interpret and act on
 122 others' declarations.  There is also no way to limit the scope of this
 123 ownertrust (e.g. "I trust my co-worker to properly identify anyone in
 124 our company, but would prefer not to trust him to identify my bank").
 125
 126 [Trust
 127 signatures](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) are a
 128 way to address these concerns.  With a trust signature, I can announce
 129 to the world that i think my sister's certifications are legitimate.
 130 She is a "trusted introducer".  If i use "trust level 1", this is
 131 equivalent to my ownertrust declaration, except that i can now make it
 132 formally public by publishing the trust signature to any keyserver.
 133
 134 If you trust my judgement in this area ([the
 135 spec](http://tools.ietf.org/html/rfc4880#section-5.2.3.13) calls my
 136 role in this scenario a "meta introducer"), then you should be able to
 137 automatically accept certifications made by my sister by creating a
 138 level 2 trust signature on my key.  You can choose whether to publish
 139 this trust signature or not, but as long as your `gpg` instance knows
 140 about it, my sister's certifications will be treated as legitimate.
 141
 142 Combining trust signatures with [regular
 143 expressions](http://tools.ietf.org/html/rfc4880#section-5.2.3.14)
 144 allows you to scope your trust declarations.  So, for example, if you
 145 work at ExampleCo, you might indicate in a standard level 1 trust
 146 signature on your co-worker's key that you trust them to identify any
 147 User ID within the `example.com` domain.
 148
 149 ### Problems and Questions with Chained Trust ###
 150
 151 How do partial/marginal ownertrust and chained trust connections
 152 interact?  That is, if:
 153
 154  * `A` privately grants "marginal" ownertrust for `B`, and
 155  * `B` issues a "marginal" trust signature at level 1 for `C`, and
 156  * `C` certifies `D`'s User ID and key,
 157
 158 Then what should `A` see as the calculated validity for `D`'s User ID?
 159 Surely nothing more than "marginal", but if `A` marginally trusts two
 160 other certifications on `D`, should that add up to full validity?
 161
 162 What if the chain goes out more levels than above?  Does "marginal"
 163 get more attenuated somehow as a chain of marginals gets deeper?  And
 164 how exactly does `max_cert_depth` play into all this?
 165
 166 What about regex-scoped trust signatures of level > 1?  Does the
 167 scoping apply to all dependent trust signatures?  Has this sort of
 168 thing been tested?
 169
 170
 171 ## "ultimate" ownertrust in GnuPG ##
 172
 173 Note that for a key under your sole control, which you expect to use
 174 to certify other people's User IDs, you would typically give that key
 175 "ultimate" ownertrust, which for the purposes of the calculations
 176 described here is very similar to "full".
 177
 178 The difference appears to be this: If a key with "full" ownertrust
 179 *but with no valid User IDs* makes a certification, that certification
 180 will not be considered.  But if the certifying key has "ultimate"
 181 ownertrust, then its certifications *are* considered.
 182
 183 So "full" ownertrust on a key is only meaningful as long as there is a
 184 trust path to some User ID on that key already.  "ultimate" ownertrust
 185 is meaningful anyway, because presumably you control that key.
 186
 187 ## Other references ##
 188
 189  * Much of this was gathered from experimenting with
 190    [GnuPG](http://gnupg.org/), and reading [gpg's
 191    `DETAILS`](http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/doc/DETAILS?root=GnuPG&view=markup).
 192    Unfortunately, `DETAILS` seems to often conflate the ideas of trust
 193    and validity, which can make it confusing to read.
 194
 195  * [RFC 4880](http://tools.ietf.org/html/rfc4880) is the canonical
 196    modern OpenPGP reference.  If you want to understand the pieces to
 197    this puzzle in detail, this is the place to go.  However, it
 198    doesn't describe the trust model calculations discussed here
 199    directly, but only points at them obliquely, through [the
 200    definition of trust
 201    signatures](http://tools.ietf.org/html/rfc4880#section-5.2.3.13).
 202    How your particular OpenPGP client chooses to calculate User ID
 203    validity is therefore implementation-specific.