1 [[meta title="OpenPGP Trust Models"]]
3 # OpenPGP Trust Models #
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
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)?
15 It's worth noting that there are two integral parts in this
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
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.
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).
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!)
43 ## What does "validity" mean anyway? ##
45 You see the term "validity" a lot in this context, but it has several
46 subtly different meanings:
48 First of all, someone might speak of the validity of a key itself,
49 which could mean two things:
51 * The key is cryptographically well-formed, not revoked, not expired,
52 and has reasonable self-signatures on its User ID packets.
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.
60 So the more useful definition of validity is actually *User ID
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),
69 is this User ID bound to its key with an acceptable trust path?
71 ## Examining your GPG trust database ##
73 You can see your trust database parameters like this:
75 gpg --with-colons --list-key bogusgarbagehere 2>/dev/null | head -n1
77 for me, it looks like this:
79 tru::1:1220401097:1220465006:3:1:5
81 These colon-delimited records say (in order):
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)
93 ## Classic trust model ##
95 As far as i can tell, the basic trust model is just the `3` and `1`
96 from the above description:
98 * how many certifications from keys with marginal ownertrust are
99 needed to grant full validity to a User ID on a key?
101 * how many certifications from keys with full ownertrust are needed
102 to grant full validity for a User ID on a key?
104 If either of these are satisfied, the User ID is considered to be
105 legitimately attached to its key (it is "fully" valid).
107 If there are no certifications from anyone you trust, the User ID is
108 considered to have unknown validity, which basically means "not
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
115 ## PGP trust model (Classic trust model + trust signatures) ##
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").
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.
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.
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.
149 ### Problems and Questions with Chained Trust ###
151 How do partial/marginal ownertrust and chained trust connections
152 interact? That is, if:
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,
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?
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?
166 What about regex-scoped trust signatures of level > 1? Does the
167 scoping apply to all dependent trust signatures? Has this sort of
171 ## "ultimate" ownertrust in GnuPG ##
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".
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.
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.
187 ## Other references ##
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.
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
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.