Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust
Date: Thu, 31 Jan 2019 16:36:04
Message-Id: CAAr7Pr9VbtMCLe1Di1SvmTjNR=33tOnbVwTbcFDFBnuKDFxTvQ@mail.gmail.com
In Reply to: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust by "Michał Górny"
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 >

Replies

Subject Author
Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust Kristian Fiskerstrand <k_f@g.o>