Gentoo Archives: gentoo-project

From: desultory <desultory@g.o>
To: gentoo-project@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust
Date: Sat, 02 Feb 2019 05:55:10
Message-Id: fc39280f-3175-aaae-804d-29d65a6826f0@gentoo.org
In Reply to: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust by "Michał Górny"
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