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