1 |
On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@g.o> wrote: |
2 |
|
3 |
> Hello, |
4 |
> |
5 |
> Here's first draft of proposed GLEP for establishing a WoT inside |
6 |
> Gentoo. It already incorporates some early feedback, so before you |
7 |
> start the usual shooting: making it obligatory wasn't my idea. |
8 |
> |
9 |
> --- |
10 |
> |
11 |
> --- |
12 |
> GLEP: 9999 |
13 |
> Title: Gentoo OpenPGP web of trust |
14 |
> Author: Michał Górny <mgorny@g.o> |
15 |
> Type: Standards Track |
16 |
> Status: Draft |
17 |
> Version: 1 |
18 |
> Created: 2019-01-20 |
19 |
> Last-Modified: 2019-01-31 |
20 |
> Post-History: 2019-01-31 |
21 |
> Content-Type: text/x-rst |
22 |
> --- |
23 |
> |
24 |
> Abstract |
25 |
> ======== |
26 |
> |
27 |
> In this GLEP the current status of establishing an OpenPGP web of trust |
28 |
> between Gentoo developers is described, and an argument is made for |
29 |
> pushing it forward. Advantages of a strong WoT are considered, |
30 |
> including its usefulness for sign-off real name verification. Rules for |
31 |
> creating key signatures are established, and an example of signing |
32 |
> procedure is provided. |
33 |
> |
34 |
> |
35 |
> Motivation |
36 |
> ========== |
37 |
> |
38 |
> While Gentoo observes the status of OpenPGP web of trust for many years, |
39 |
> there never has been a proper push to get all developers covered by it |
40 |
> or even formalize the rules of signing one another's keys. Apparently, |
41 |
> there are still many Gentoo developers who do not have their |
42 |
> ``@gentoo.org`` UID signed by another active developer. Historically |
43 |
> there were also cases of developers signing others' UIDs without |
44 |
> actually verifying their identity. [#WOT-GRAPH]_ [#WOT-STATS]_ |
45 |
> |
46 |
> The web of trust is usually considered secondary to Gentoo's internal |
47 |
> trust system based on key fingerprints stored in LDAP and distributing |
48 |
> via the website. While this system reliably covers all Gentoo |
49 |
> developers, it has three major drawbacks: |
50 |
> |
51 |
> 1. It is entirely customary and therefore requires customized software |
52 |
> to use. In other words, it's of limited usefulness to people outside |
53 |
> Gentoo or does not work out of the box there. |
54 |
> |
55 |
|
56 |
> 2. At least in the current form, it is entirely limited to Gentoo |
57 |
> developers. As such, it does not facilitate trust between them |
58 |
> and the outer world. |
59 |
> |
60 |
|
61 |
> 3. It relies on a centralized server whose authenticity is in turn |
62 |
> proved via PKI. This model is generally considered weak. |
63 |
> |
64 |
> Even if this trust system is to stay being central to Gentoo's needs, |
65 |
> it should be beneficial for Gentoo developers start to improving |
66 |
> the OpenPGP web of trust, both for the purpose of improving Gentoo's |
67 |
> position in it and for the purpose of enabling better trust coverage |
68 |
> between Gentoo developers, users and other people. |
69 |
> |
70 |
> Furthermore, the recent copyright policy established in GLEP 76 |
71 |
> introduces the necessity of verifying real names of developers. Given |
72 |
> that the Foundation wishes to avoid requesting document scans or other |
73 |
> form of direct verification, the identity verification required |
74 |
> for UID signing can also serve the needs of verifying the name |
75 |
> for Certificate of Origin sign-off purposes. [#GLEP76]_ |
76 |
> |
77 |
> |
78 |
My main problem with the GLEP is that it seems to propose a WoT for a WoT's |
79 |
sake and my question then becomes "why do we need a WoT?" |
80 |
|
81 |
As in, what does a WoT enable the project to do that it cannot do now? |
82 |
|
83 |
-A |
84 |
|
85 |
|
86 |
> |
87 |
> Specification |
88 |
> ============= |
89 |
> |
90 |
> Signature requirements |
91 |
> ---------------------- |
92 |
> |
93 |
> As a final goal of this GLEP, each Gentoo developer will be required |
94 |
> to have at least one signature from another Gentoo developer or from |
95 |
> member of one of the partner communities present on their |
96 |
> ``@gentoo.org`` UID. |
97 |
> |
98 |
> Recruits will be required to obtain such a signature on one of their |
99 |
> user identifiers containing their real name before becoming Gentoo |
100 |
> developers. After obtaining the ``@gentoo.org`` e-mail address, they |
101 |
> will be required to add it to their OpenPGP key and obtain a signature |
102 |
> on it as well before obtaining commit access (this requires only e-mail |
103 |
> exchange with previous signer). |
104 |
> |
105 |
> Transitional (grandfathering) period will be provided based on two |
106 |
> milestones: |
107 |
> |
108 |
> - newly joining developers will be required to have their key signed |
109 |
> prior to joining starting 2019-10-01, |
110 |
> |
111 |
> - all existing developers will be required to have their key signed |
112 |
> starting 2020-07-01. |
113 |
> |
114 |
> If necessity arises, the Council may defer the milestones and extend |
115 |
> the transitional period. |
116 |
> |
117 |
> |
118 |
> Key signing rules |
119 |
> ----------------- |
120 |
> |
121 |
> When signing an OpenPGP key belonging to another person, the following |
122 |
> rules need to be respected: |
123 |
> |
124 |
> 1. Sign only those user identifiers which you have successfully |
125 |
> verified. Do not sign all identifiers unless you have previously |
126 |
> verified all of them. |
127 |
> |
128 |
> 2. For the purpose of Gentoo sign-off usage, the key must have |
129 |
> an identifier consisting of the real name of a natural person |
130 |
> (per GLEP 76) and the respective e-mail address to be used |
131 |
> in ``Signed-off-by`` line. In case of Gentoo developers, this e-mail |
132 |
> address has to be their ``@gentoo.org`` address. |
133 |
> |
134 |
> Other user identifiers do not need to strictly follow those rules, |
135 |
> and may be skipped for the purpose of Gentoo key signing. However, |
136 |
> you should follow the respective rules for verifying those kind |
137 |
> of identifiers (e.g. XMPP UIDs should be signed after verifying |
138 |
> the working XEP-0373 or similar encryption, keybase.io UIDs should |
139 |
> follow appropriate keybase verification). [#XEP-0373]_ |
140 |
> [#KEYBASE.IO]_ |
141 |
> |
142 |
> 3. Before signing a user identifier, make sure to: |
143 |
> |
144 |
> a. Obtain a fingerprint of the person's primary key (for the purpose |
145 |
> of verifying the authenticity of the key you're about to sign). |
146 |
> Usually, a printed strip containing ``gpg --list-key`` output |
147 |
> is used for this purpose. |
148 |
> |
149 |
> b. Verify the person's real name (at least for the user identifier |
150 |
> used for copyright purposes). This is usually done through |
151 |
> verifying an identification document with photograph. It is |
152 |
> a good idea to ask for the document type earlier, and read on |
153 |
> forgery protections used. |
154 |
> |
155 |
> In some cases, alternate methods of verifying the identity may be |
156 |
> used if they provide equivalent or better level of reliability. |
157 |
> This can include e.g. use of national online identification |
158 |
> systems or bank transfers. |
159 |
> |
160 |
> c. Verify that the person has access to the corresponding e-mail |
161 |
> address / web resource, e.g. by sending a block of randomly |
162 |
> generated data and requesting sending it back, signed using |
163 |
> the respective key. |
164 |
> |
165 |
> 4. Once you signed a single user identifier of a particular person, you |
166 |
> can sign new user identifiers by just verifying the e-mail address |
167 |
> without repeating identity verification (provided the new UIDs share |
168 |
> the same real name). |
169 |
> |
170 |
> 5. If you have reasons to believe that the particular person has lost |
171 |
> access to the respective e-mail address (e.g. due to retirement), |
172 |
> that the real name is no longer valid or the user identifier became |
173 |
> invalid for any other reason, you should revoke your previous |
174 |
> signature on it. |
175 |
> |
176 |
> |
177 |
> Key signing partners |
178 |
> -------------------- |
179 |
> |
180 |
> In order to improve key signing accessibility to developers, Gentoo will |
181 |
> accept signatures made by members of partner communities. The list |
182 |
> of partner communities will be maintained in Gentoo Wiki [TODO]. New |
183 |
> communities will be added to the list only if they have compatible key |
184 |
> signing rules and they agree to it. |
185 |
> |
186 |
> |
187 |
> Example key signing process (informative) |
188 |
> ----------------------------------------- |
189 |
> |
190 |
> Let's consider that Alice is planning to meet Bob and sign his OpenPGP |
191 |
> key. In this section, we will only consider the process of signing |
192 |
> Bob's key from Alice's perspective. Usually, at the same time Bob would |
193 |
> sign Alice's key — with an equivalent process. |
194 |
> |
195 |
> Bob has printed the output of ``gpg --list-keys`` for his key, and gives |
196 |
> it to Alice. It contains the following text:: |
197 |
> |
198 |
> pub rsa2048 2019-01-23 [SC] [expires: 2021-01-22] |
199 |
> 6CDE875E9CCF01D6E5691C9561FB7991B3D45B3C |
200 |
> uid [ultimate] Robert Someone <bob@×××××××.com> |
201 |
> uid [ultimate] Robert Someone <bob2@×××××××.org> |
202 |
> sub rsa2048 2019-01-23 [E] [expires: 2021-01-22] |
203 |
> |
204 |
> Alice verifies the Bob's identity. He gives her his ID card, stating:: |
205 |
> |
206 |
> Given name: Robert |
207 |
> Family name: Someone |
208 |
> |
209 |
> Ideally, Alice would have known what kind of document to expected |
210 |
> and would have read up on verifying it. After verifying that |
211 |
> the document looks legitimate, and the photograph reasonably matches |
212 |
> Bob, she has confirmed Bob's real name. |
213 |
> |
214 |
> Afterwards, she prepares two chunks of random data, e.g. by doing:: |
215 |
> |
216 |
> dd if=/dev/urandom bs=1k count=1 | base64 |
217 |
> |
218 |
> She sends the first of them to ``bob@×××××××.com``, and the second one |
219 |
> to ``bob2@×××××××.com``. Bob replies by quoting the received chunk, |
220 |
> and signing his mail using his OpenPGP key. Once Alice receives |
221 |
> the reply, she verifies the content and the fingerprint of primary key |
222 |
> corresponding to the signature. If they match, she has confirmed Bob's |
223 |
> e-mail addresses. |
224 |
> |
225 |
> At this point, she can sign both of Bob's UIDs. |
226 |
> |
227 |
> |
228 |
> Rationale |
229 |
> ========= |
230 |
> |
231 |
> Milestones |
232 |
> ---------- |
233 |
> |
234 |
> The transitional period is provided so that developers currently missing |
235 |
> user signatures are given time to obtain them. Initially, the period |
236 |
> is set to roughly one and half year but can be extended if the adoption |
237 |
> is problematic. |
238 |
> |
239 |
> Additionally, a half as long transitional period is provided for new |
240 |
> developers. This is meant to avoid blocking recruitment while the key |
241 |
> signing network is still being built. |
242 |
> |
243 |
> |
244 |
> Rules |
245 |
> ----- |
246 |
> |
247 |
> The rules aim to reiterate the common web of trust practices. Firstly, |
248 |
> they emphasize the fact that signatures are done per user identifier |
249 |
> and not per key, and therefore each identifier signed needs to be |
250 |
> verified. Appropriately, you don't have to sign all the user |
251 |
> identifiers immediately or at all. |
252 |
> |
253 |
> The policy is focused around standard user identifiers, consisting |
254 |
> of a real name and an e-mail address. In context of those, it requires |
255 |
> at least a single identifier that actually has a real name for GLEP 67 |
256 |
> purposes. It also indicates that there can be other kinds of user |
257 |
> identifiers that may require different verification rules. |
258 |
> |
259 |
> The actual verification of each user identifier consists of confirming |
260 |
> three relevant parts: primary key fingerprint, real name and e-mail |
261 |
> address (or their equivalents in other kinds of user identifiers). |
262 |
> |
263 |
> The primary key fingerprint is used to obtain the correct key to sign, |
264 |
> and to prevent a malicious third party from providing you with a forged |
265 |
> key. Real name and e-mail verification is used to confirm |
266 |
> the authenticity of each user identifier being signed. Use of random |
267 |
> data in e-mail makes it possible to clearly confirm that the same person |
268 |
> is both in possession of the e-mail address and the private keys. |
269 |
> |
270 |
> Once an identity is verified once, there is no reason to verify it again |
271 |
> to sign further user identifiers using the same name. This is helpful |
272 |
> e.g. when a person obtains new e-mail addresses, and wishes to get them |
273 |
> signed. In that case, new signatures can be added after verifying |
274 |
> the e-mail address, and confirming match with the prior verified name. |
275 |
> |
276 |
> Finally, since user identifier signatures are normally non-expiring |
277 |
> and therefore indicate perpetual trust, it is reasonable to revoke them |
278 |
> when the identifiers stop being valid. |
279 |
> |
280 |
> |
281 |
> Partner communities |
282 |
> ------------------- |
283 |
> |
284 |
> Both to improve global web of trust coverage, and to avoid requiring |
285 |
> developers to travel abroad to meet other Gentoo developers, the policy |
286 |
> accounts for establishing partnership with other communities using |
287 |
> OpenPGP. Those partnerships will increase the chances that Gentoo |
288 |
> developers and recruits will be able to obtain a valid signature nearer |
289 |
> to their locality. |
290 |
> |
291 |
> In order to maintain a reasonable quality of signatures, only |
292 |
> communities respecting similar rules will be accepted (e.g. verifying |
293 |
> identities of developers). Additionally, the communities will be |
294 |
> contacted first to avoid adding them against their will. |
295 |
> |
296 |
> |
297 |
> Web of trust in other open source projects |
298 |
> ------------------------------------------ |
299 |
> |
300 |
> Debian requires all developers to obtain a signature from at least two |
301 |
> existing developers before joining. They also explicitly note |
302 |
> the necessity of verifying identity. In case it's really impossible to |
303 |
> meet another developer, the Front Desk (equivalent of Recruiters) may |
304 |
> offer an alternative way of identification. [#DEBIAN-IDENTIFICATION]_ |
305 |
> |
306 |
> NetBSD requires all applicants to sign the application with a key that |
307 |
> is already signed by at least one NetBSD developer. [#NETBSD-PGP]_ |
308 |
> |
309 |
> |
310 |
> Backwards Compatibility |
311 |
> ======================= |
312 |
> |
313 |
> Gentoo does not use any particular web of trust policy at the moment. |
314 |
> Not all of existing signatures conform to the new policy. Therefore, |
315 |
> approving it is going to require, in some cases: |
316 |
> |
317 |
> a. replacing non-conformant user identifiers, |
318 |
> |
319 |
> b. revoking non-conformant signatures. |
320 |
> |
321 |
> Naturally, those actions can only be carried off by cooperating key |
322 |
> owners. |
323 |
> |
324 |
> The policy specifies transitional periods for developers whose keys are |
325 |
> not signed by anyone in the community yet. |
326 |
> |
327 |
> |
328 |
> Reference Implementation |
329 |
> ======================== |
330 |
> |
331 |
> n/a |
332 |
> |
333 |
> |
334 |
> References |
335 |
> ========== |
336 |
> |
337 |
> .. [#WOT-GRAPH] Gentoo Dev Web of Trust (WoT) |
338 |
> (https://qa-reports.gentoo.org/output/wot-graph.svg) |
339 |
> |
340 |
> .. [#WOT-STATS] WoT Node Stats |
341 |
> (https://qa-reports.gentoo.org/output/wot-stats.html) |
342 |
> |
343 |
> .. [#GLEP76] GLEP 76: Copyright Policy |
344 |
> (https://www.gentoo.org/glep/glep-0076.html) |
345 |
> |
346 |
> .. [#XEP-0373] XEP-0373: OpenPGP for XMPP |
347 |
> (https://xmpp.org/extensions/xep-0373.html) |
348 |
> |
349 |
> .. [#KEYBASE.IO] Keybase |
350 |
> (https://keybase.io/) |
351 |
> |
352 |
> .. [#DEBIAN-IDENTIFICATION] Debian -- Step 2: Identification |
353 |
> (https://www.debian.org/devel/join/nm-step2.en.html) |
354 |
> |
355 |
> .. [#NETBSD-PGP] PGP Key Management Guide for NetBSD developers |
356 |
> (https://www.netbsd.org/developers/pgp.html) |
357 |
> |
358 |
> |
359 |
> Copyright |
360 |
> ========= |
361 |
> This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 |
362 |
> Unported License. To view a copy of this license, visit |
363 |
> http://creativecommons.org/licenses/by-sa/3.0/. |
364 |
> |
365 |
> |
366 |
> -- |
367 |
> Best regards, |
368 |
> Michał Górny |
369 |
> |