1 |
On 01/31/19 08:56, Michał Górny wrote: |
2 |
> Hello, |
3 |
> |
4 |
> Here's first draft of proposed GLEP for establishing a WoT inside |
5 |
> Gentoo. It already incorporates some early feedback, so before you |
6 |
> start the usual shooting: making it obligatory wasn't my idea. |
7 |
> |
8 |
Have some faith in your fellow developers, most don't tend to |
9 |
communicates in ad hominem. Also, have some faith in yourself, it is not |
10 |
a bad idea just because you posted it, it is a bad idea on it's own |
11 |
(lack of) merit. |
12 |
|
13 |
> --- |
14 |
> |
15 |
> --- |
16 |
> GLEP: 9999 |
17 |
> Title: Gentoo OpenPGP web of trust |
18 |
> Author: Michał Górny <mgorny@g.o> |
19 |
> Type: Standards Track |
20 |
> Status: Draft |
21 |
> Version: 1 |
22 |
> Created: 2019-01-20 |
23 |
> Last-Modified: 2019-01-31 |
24 |
> Post-History: 2019-01-31 |
25 |
> Content-Type: text/x-rst |
26 |
> --- |
27 |
> |
28 |
> Abstract |
29 |
> ======== |
30 |
> |
31 |
> In this GLEP the current status of establishing an OpenPGP web of trust |
32 |
> between Gentoo developers is described, and an argument is made for |
33 |
> pushing it forward. Advantages of a strong WoT are considered, |
34 |
> including its usefulness for sign-off real name verification. Rules for |
35 |
> creating key signatures are established, and an example of signing |
36 |
> procedure is provided. |
37 |
> |
38 |
> |
39 |
> Motivation |
40 |
> ========== |
41 |
> |
42 |
> While Gentoo observes the status of OpenPGP web of trust for many years, |
43 |
> there never has been a proper push to get all developers covered by it |
44 |
> or even formalize the rules of signing one another's keys. Apparently, |
45 |
> there are still many Gentoo developers who do not have their |
46 |
> ``@gentoo.org`` UID signed by another active developer. Historically |
47 |
> there were also cases of developers signing others' UIDs without |
48 |
> actually verifying their identity. [#WOT-GRAPH]_ [#WOT-STATS]_ |
49 |
> |
50 |
I have been affiliated with Gentoo for over a decade now, I have never |
51 |
needed to use my GPG keys for anything beyond verifying that they |
52 |
worked. I have never needed to have them signed by anyone or anything |
53 |
that wasn't automated. In over a decade. |
54 |
|
55 |
> The web of trust is usually considered secondary to Gentoo's internal |
56 |
> trust system based on key fingerprints stored in LDAP and distributing |
57 |
> via the website. While this system reliably covers all Gentoo |
58 |
> developers, it has three major drawbacks: |
59 |
> |
60 |
> 1. It is entirely customary and therefore requires customized software |
61 |
> to use. In other words, it's of limited usefulness to people outside |
62 |
> Gentoo or does not work out of the box there. |
63 |
> |
64 |
The custom software is, as one might infer, already in existence and |
65 |
already operating, and has been for some time. Th role of the software |
66 |
in question is to be *internally* useful, being useful to third parties |
67 |
is outside of the problem space it is meant to address. |
68 |
|
69 |
> 2. At least in the current form, it is entirely limited to Gentoo |
70 |
> developers. As such, it does not facilitate trust between them |
71 |
> and the outer world. |
72 |
> |
73 |
Which is entirely in keeping with its design and intended use; in short, |
74 |
this not a bug.. |
75 |
|
76 |
> 3. It relies on a centralized server whose authenticity is in turn |
77 |
> proved via PKI. This model is generally considered weak. |
78 |
> |
79 |
However weak you may consider it to be, it has been sufficient for its |
80 |
purpose for quite some time. |
81 |
|
82 |
> Even if this trust system is to stay being central to Gentoo's needs, |
83 |
> it should be beneficial for Gentoo developers start to improving |
84 |
> the OpenPGP web of trust, both for the purpose of improving Gentoo's |
85 |
> position in it and for the purpose of enabling better trust coverage |
86 |
> between Gentoo developers, users and other people. |
87 |
> |
88 |
And this is where things really start to go off the rails: "improving |
89 |
Gentoo's position in" the web of trust rather strongly implies a deep |
90 |
misunderstanding of how the system works and why it works the way it |
91 |
does. Gaming a system that you do not understand is not likely to go well. |
92 |
> Furthermore, the recent copyright policy established in GLEP 76 |
93 |
> introduces the necessity of verifying real names of developers. Given |
94 |
> that the Foundation wishes to avoid requesting document scans or other |
95 |
> form of direct verification, the identity verification required |
96 |
> for UID signing can also serve the needs of verifying the name |
97 |
> for Certificate of Origin sign-off purposes. [#GLEP76]_ |
98 |
> |
99 |
No, it doesn't. GLEP 76 makes the assertion that "The sign-off must |
100 |
contain the committer's legal name as a natural person, i.e., the name |
101 |
that would appear in a government issued document.", it does not |
102 |
prescribe institutional confirmation of that "legal name as a natural |
103 |
person". The implication is, at least if one is to read the document as |
104 |
written, that the individual signing off on the commit is affirming that |
105 |
they are using their "legal name as a natural person". |
106 |
> |
107 |
> Specification |
108 |
> ============= |
109 |
> |
110 |
> Signature requirements |
111 |
> ---------------------- |
112 |
> |
113 |
> As a final goal of this GLEP, each Gentoo developer will be required |
114 |
> to have at least one signature from another Gentoo developer or from |
115 |
> member of one of the partner communities present on their |
116 |
> ``@gentoo.org`` UID. |
117 |
> > Recruits will be required to obtain such a signature on one of their |
118 |
> user identifiers containing their real name before becoming Gentoo |
119 |
> developers. After obtaining the ``@gentoo.org`` e-mail address, they |
120 |
> will be required to add it to their OpenPGP key and obtain a signature |
121 |
> on it as well before obtaining commit access (this requires only e-mail |
122 |
> exchange with previous signer). |
123 |
> |
124 |
> Transitional (grandfathering) period will be provided based on two |
125 |
> milestones: |
126 |
> |
127 |
> - newly joining developers will be required to have their key signed |
128 |
> prior to joining starting 2019-10-01, |
129 |
> |
130 |
> - all existing developers will be required to have their key signed |
131 |
> starting 2020-07-01. |
132 |
> |
133 |
> If necessity arises, the Council may defer the milestones and extend |
134 |
> the transitional period. |
135 |
> |
136 |
> |
137 |
> Key signing rules |
138 |
> ----------------- |
139 |
> |
140 |
> When signing an OpenPGP key belonging to another person, the following |
141 |
> rules need to be respected: |
142 |
> |
143 |
> 1. Sign only those user identifiers which you have successfully |
144 |
> verified. Do not sign all identifiers unless you have previously |
145 |
> verified all of them. |
146 |
> |
147 |
This seems to logically conflict with point 4. |
148 |
|
149 |
> 2. For the purpose of Gentoo sign-off usage, the key must have |
150 |
> an identifier consisting of the real name of a natural person |
151 |
> (per GLEP 76) and the respective e-mail address to be used |
152 |
> in ``Signed-off-by`` line. In case of Gentoo developers, this e-mail |
153 |
> address has to be their ``@gentoo.org`` address. |
154 |
> |
155 |
> Other user identifiers do not need to strictly follow those rules, |
156 |
> and may be skipped for the purpose of Gentoo key signing. However, |
157 |
> you should follow the respective rules for verifying those kind |
158 |
> of identifiers (e.g. XMPP UIDs should be signed after verifying |
159 |
> the working XEP-0373 or similar encryption, keybase.io UIDs should |
160 |
> follow appropriate keybase verification). [#XEP-0373]_ |
161 |
> [#KEYBASE.IO]_ |
162 |
> |
163 |
> 3. Before signing a user identifier, make sure to: |
164 |
> |
165 |
> a. Obtain a fingerprint of the person's primary key (for the purpose |
166 |
> of verifying the authenticity of the key you're about to sign). |
167 |
> Usually, a printed strip containing ``gpg --list-key`` output |
168 |
> is used for this purpose. |
169 |
> |
170 |
> b. Verify the person's real name (at least for the user identifier |
171 |
> used for copyright purposes). This is usually done through |
172 |
> verifying an identification document with photograph. It is |
173 |
> a good idea to ask for the document type earlier, and read on |
174 |
> forgery protections used. |
175 |
> |
176 |
Are you, in the general sense regarding the authors of this proposal, |
177 |
seriously suggesting that random developers should become self-educated |
178 |
expert identity document verifiers? This seems... questionably plausible. |
179 |
|
180 |
> In some cases, alternate methods of verifying the identity may be |
181 |
> used if they provide equivalent or better level of reliability. |
182 |
> This can include e.g. use of national online identification |
183 |
> systems or bank transfers. |
184 |
> |
185 |
How, exactly, is a bank transfer a better means of establishing ones |
186 |
"legal name as a natural person"? |
187 |
|
188 |
> c. Verify that the person has access to the corresponding e-mail |
189 |
> address / web resource, e.g. by sending a block of randomly |
190 |
> generated data and requesting sending it back, signed using |
191 |
> the respective key. |
192 |
> |
193 |
The specific requirement for "randomly generated data" is pointless in |
194 |
any realistic scenario. |
195 |
|
196 |
> 4. Once you signed a single user identifier of a particular person, you |
197 |
> can sign new user identifiers by just verifying the e-mail address |
198 |
> without repeating identity verification (provided the new UIDs share |
199 |
> the same real name). |
200 |
> |
201 |
> 5. If you have reasons to believe that the particular person has lost |
202 |
> access to the respective e-mail address (e.g. due to retirement), |
203 |
> that the real name is no longer valid or the user identifier became |
204 |
> invalid for any other reason, you should revoke your previous |
205 |
> signature on it. |
206 |
> |
207 |
Revoking "trust" upon retirement, when the identity would be |
208 |
functionally disabled with respect to Gentoo regardless, seems |
209 |
pointless. Revoking "trust" upon legal name change is logically |
210 |
pointless. Given the recommendation to create and retain a revocation |
211 |
certificate for PGP keys, recommending that "trust" be revoked by others |
212 |
is arguably redundant. [GLEP63] |
213 |
|
214 |
> |
215 |
> Key signing partners |
216 |
> -------------------- |
217 |
> |
218 |
> In order to improve key signing accessibility to developers, Gentoo will |
219 |
> accept signatures made by members of partner communities. The list |
220 |
> of partner communities will be maintained in Gentoo Wiki [TODO]. New |
221 |
> communities will be added to the list only if they have compatible key |
222 |
> signing rules and they agree to it. |
223 |
> |
224 |
Even if only for the sake of general example, outside of the proposal |
225 |
itself, there really should be some indication of what "partner |
226 |
communities" are being considered. |
227 |
|
228 |
> |
229 |
> Example key signing process (informative) |
230 |
> ----------------------------------------- |
231 |
> |
232 |
> Let's consider that Alice is planning to meet Bob and sign his OpenPGP |
233 |
> key. In this section, we will only consider the process of signing |
234 |
> Bob's key from Alice's perspective. Usually, at the same time Bob would |
235 |
> sign Alice's key — with an equivalent process. |
236 |
> |
237 |
> Bob has printed the output of ``gpg --list-keys`` for his key, and gives |
238 |
> it to Alice. It contains the following text:: |
239 |
> |
240 |
> pub rsa2048 2019-01-23 [SC] [expires: 2021-01-22] |
241 |
> 6CDE875E9CCF01D6E5691C9561FB7991B3D45B3C |
242 |
> uid [ultimate] Robert Someone <bob@×××××××.com> |
243 |
> uid [ultimate] Robert Someone <bob2@×××××××.org> |
244 |
> sub rsa2048 2019-01-23 [E] [expires: 2021-01-22] |
245 |
> |
246 |
> Alice verifies the Bob's identity. He gives her his ID card, stating:: |
247 |
> |
248 |
> Given name: Robert |
249 |
> Family name: Someone |
250 |
> |
251 |
> Ideally, Alice would have known what kind of document to expected |
252 |
> and would have read up on verifying it. After verifying that |
253 |
> the document looks legitimate, and the photograph reasonably matches |
254 |
> Bob, she has confirmed Bob's real name. |
255 |
> |
256 |
Again, this is, according to the supposed "threat model" (ie people who |
257 |
are using false identities and have even the slightest degree of |
258 |
competence in that area) expecting a degree of expertise which is |
259 |
unrealistic. |
260 |
|
261 |
> Afterwards, she prepares two chunks of random data, e.g. by doing:: |
262 |
> |
263 |
> dd if=/dev/urandom bs=1k count=1 | base64 |
264 |
> |
265 |
> She sends the first of them to ``bob@×××××××.com``, and the second one |
266 |
> to ``bob2@×××××××.com``. Bob replies by quoting the received chunk, |
267 |
> and signing his mail using his OpenPGP key. Once Alice receives |
268 |
> the reply, she verifies the content and the fingerprint of primary key |
269 |
> corresponding to the signature. If they match, she has confirmed Bob's |
270 |
> e-mail addresses. |
271 |
> |
272 |
> At this point, she can sign both of Bob's UIDs. |
273 |
> |
274 |
> |
275 |
> Rationale |
276 |
> ========= |
277 |
> |
278 |
> Milestones |
279 |
> ---------- |
280 |
> |
281 |
> The transitional period is provided so that developers currently missing |
282 |
> user signatures are given time to obtain them. Initially, the period |
283 |
> is set to roughly one and half year but can be extended if the adoption |
284 |
> is problematic. |
285 |
> |
286 |
> Additionally, a half as long transitional period is provided for new |
287 |
> developers. This is meant to avoid blocking recruitment while the key |
288 |
> signing network is still being built. |
289 |
> |
290 |
Given that Gentoo is perpetually understaffed in various areas, and the |
291 |
single issue that most often comes up as a reason for people to not join |
292 |
and take a more active role is that it involves too much pointless work |
293 |
to get their commit bit set, this proposal seeks to require pointless |
294 |
work which many would out of principle not do and others are simply |
295 |
unable to actually comply with. This seems sub-optimal. |
296 |
|
297 |
> |
298 |
> Rules |
299 |
> ----- |
300 |
> |
301 |
> The rules aim to reiterate the common web of trust practices. Firstly, |
302 |
> they emphasize the fact that signatures are done per user identifier |
303 |
> and not per key, and therefore each identifier signed needs to be |
304 |
> verified. Appropriately, you don't have to sign all the user |
305 |
> identifiers immediately or at all. |
306 |
> |
307 |
> The policy is focused around standard user identifiers, consisting |
308 |
> of a real name and an e-mail address. In context of those, it requires |
309 |
> at least a single identifier that actually has a real name for GLEP 67 |
310 |
GLEP 76 [GLEP76], GLEP 67 [GLEP67] seems at most tangentially related. |
311 |
|
312 |
> purposes. It also indicates that there can be other kinds of user |
313 |
> identifiers that may require different verification rules. |
314 |
> |
315 |
> The actual verification of each user identifier consists of confirming |
316 |
> three relevant parts: primary key fingerprint, real name and e-mail |
317 |
> address (or their equivalents in other kinds of user identifiers). |
318 |
> |
319 |
> The primary key fingerprint is used to obtain the correct key to sign, |
320 |
> and to prevent a malicious third party from providing you with a forged |
321 |
> key. Real name and e-mail verification is used to confirm |
322 |
> the authenticity of each user identifier being signed. Use of random |
323 |
> data in e-mail makes it possible to clearly confirm that the same person |
324 |
> is both in possession of the e-mail address and the private keys. |
325 |
> |
326 |
The randomness in the "random data" is not required to function as |
327 |
claimed, simply using different data, per user, suffices. |
328 |
|
329 |
> Once an identity is verified once, there is no reason to verify it again |
330 |
> to sign further user identifiers using the same name. This is helpful |
331 |
> e.g. when a person obtains new e-mail addresses, and wishes to get them |
332 |
> signed. In that case, new signatures can be added after verifying |
333 |
> the e-mail address, and confirming match with the prior verified name. |
334 |
> |
335 |
Functionally, this appear to be counter to point 1, above. |
336 |
|
337 |
> Finally, since user identifier signatures are normally non-expiring |
338 |
> and therefore indicate perpetual trust, it is reasonable to revoke them |
339 |
> when the identifiers stop being valid. |
340 |
> |
341 |
Arguably reasonable to recommend, generally pointless in practice. |
342 |
|
343 |
> |
344 |
> Partner communities |
345 |
> ------------------- |
346 |
> |
347 |
> Both to improve global web of trust coverage, and to avoid requiring |
348 |
> developers to travel abroad to meet other Gentoo developers, the policy |
349 |
> accounts for establishing partnership with other communities using |
350 |
> OpenPGP. Those partnerships will increase the chances that Gentoo |
351 |
> developers and recruits will be able to obtain a valid signature nearer |
352 |
> to their locality. |
353 |
> |
354 |
> In order to maintain a reasonable quality of signatures, only |
355 |
> communities respecting similar rules will be accepted (e.g. verifying |
356 |
> identities of developers). Additionally, the communities will be |
357 |
> contacted first to avoid adding them against their will. |
358 |
> |
359 |
> |
360 |
> Web of trust in other open source projects |
361 |
> ------------------------------------------ |
362 |
> |
363 |
> Debian requires all developers to obtain a signature from at least two |
364 |
> existing developers before joining. They also explicitly note |
365 |
> the necessity of verifying identity. In case it's really impossible to |
366 |
> meet another developer, the Front Desk (equivalent of Recruiters) may |
367 |
> offer an alternative way of identification. [#DEBIAN-IDENTIFICATION]_ |
368 |
> |
369 |
> NetBSD requires all applicants to sign the application with a key that |
370 |
> is already signed by at least one NetBSD developer. [#NETBSD-PGP]_ |
371 |
> |
372 |
Bother are statements that they have such requirements, neither |
373 |
addresses any benefit from them. As such, this section is pointless. |
374 |
|
375 |
> |
376 |
> Backwards Compatibility |
377 |
> ======================= |
378 |
> |
379 |
> Gentoo does not use any particular web of trust policy at the moment. |
380 |
> Not all of existing signatures conform to the new policy. Therefore, |
381 |
> approving it is going to require, in some cases: |
382 |
> |
383 |
> a. replacing non-conformant user identifiers, |
384 |
> |
385 |
> b. revoking non-conformant signatures. |
386 |
> |
387 |
> Naturally, those actions can only be carried off by cooperating key |
388 |
> owners. |
389 |
> |
390 |
> The policy specifies transitional periods for developers whose keys are |
391 |
> not signed by anyone in the community yet. |
392 |
> |
393 |
The policy makes no effort to describe what would happen to developers |
394 |
who, for whatever reason, were not compliant by the end of the proposed |
395 |
transition period. This has been, by multiple people in this thread, |
396 |
inferred to indicate that they will be forcibly retired Leaving what |
397 |
would appear to be fundamental concerns to inference is sub-optimal. |
398 |
|
399 |
> |
400 |
> Reference Implementation |
401 |
> ======================== |
402 |
> |
403 |
> n/a |
404 |
> |
405 |
> |
406 |
> References |
407 |
> ========== |
408 |
> |
409 |
> .. [#WOT-GRAPH] Gentoo Dev Web of Trust (WoT) |
410 |
> (https://qa-reports.gentoo.org/output/wot-graph.svg) |
411 |
> |
412 |
> .. [#WOT-STATS] WoT Node Stats |
413 |
> (https://qa-reports.gentoo.org/output/wot-stats.html) |
414 |
> |
415 |
> .. [#GLEP76] GLEP 76: Copyright Policy |
416 |
> (https://www.gentoo.org/glep/glep-0076.html) |
417 |
> |
418 |
> .. [#XEP-0373] XEP-0373: OpenPGP for XMPP |
419 |
> (https://xmpp.org/extensions/xep-0373.html) |
420 |
> |
421 |
> .. [#KEYBASE.IO] Keybase |
422 |
> (https://keybase.io/) |
423 |
> |
424 |
> .. [#DEBIAN-IDENTIFICATION] Debian -- Step 2: Identification |
425 |
> (https://www.debian.org/devel/join/nm-step2.en.html) |
426 |
> |
427 |
> .. [#NETBSD-PGP] PGP Key Management Guide for NetBSD developers |
428 |
> (https://www.netbsd.org/developers/pgp.html) |
429 |
> |
430 |
> |
431 |
> Copyright |
432 |
> ========= |
433 |
> This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 |
434 |
> Unported License. To view a copy of this license, visit |
435 |
> http://creativecommons.org/licenses/by-sa/3.0/. |
436 |
> |
437 |
> |
438 |
|
439 |
[GLEP63] https://www.gentoo.org/glep/glep-0063.html |
440 |
[GLEP67] https://www.gentoo.org/glep/glep-0067.html |
441 |
[GLEP76] https://www.gentoo.org/glep/glep-0076.html |