preparing for stupid brown paper bag 0.23.1 release.
[monkeysphere.git] / 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.