Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust
Date: Thu, 31 Jan 2019 13:56:57
1 Hello,
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.
7 ---
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 ---
22 Abstract
23 ========
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.
33 Motivation
34 ==========
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 ```` 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]_
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:
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.
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.
57 3. It relies on a centralized server whose authenticity is in turn
58 proved via PKI. This model is generally considered weak.
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.
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]_
74 Specification
75 =============
77 Signature requirements
78 ----------------------
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 ```` UID.
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 ```` 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).
92 Transitional (grandfathering) period will be provided based on two
93 milestones:
95 - newly joining developers will be required to have their key signed
96 prior to joining starting 2019-10-01,
98 - all existing developers will be required to have their key signed
99 starting 2020-07-01.
101 If necessity arises, the Council may defer the milestones and extend
102 the transitional period.
105 Key signing rules
106 -----------------
108 When signing an OpenPGP key belonging to another person, the following
109 rules need to be respected:
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.
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 ```` address.
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, UIDs should
126 follow appropriate keybase verification). [#XEP-0373]_
127 [#KEYBASE.IO]_
129 3. Before signing a user identifier, make sure to:
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.
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.
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.
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.
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).
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.
164 Key signing partners
165 --------------------
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.
174 Example key signing process (informative)
175 -----------------------------------------
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.
182 Bob has printed the output of ``gpg --list-keys`` for his key, and gives
183 it to Alice. It contains the following text::
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]
191 Alice verifies the Bob's identity. He gives her his ID card, stating::
193 Given name: Robert
194 Family name: Someone
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.
201 Afterwards, she prepares two chunks of random data, e.g. by doing::
203 dd if=/dev/urandom bs=1k count=1 | base64
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.
212 At this point, she can sign both of Bob's UIDs.
215 Rationale
216 =========
218 Milestones
219 ----------
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.
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.
231 Rules
232 -----
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.
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.
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).
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.
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.
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.
268 Partner communities
269 -------------------
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.
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.
284 Web of trust in other open source projects
285 ------------------------------------------
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]_
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]_
297 Backwards Compatibility
298 =======================
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:
304 a. replacing non-conformant user identifiers,
306 b. revoking non-conformant signatures.
308 Naturally, those actions can only be carried off by cooperating key
309 owners.
311 The policy specifies transitional periods for developers whose keys are
312 not signed by anyone in the community yet.
315 Reference Implementation
316 ========================
318 n/a
321 References
322 ==========
324 .. [#WOT-GRAPH] Gentoo Dev Web of Trust (WoT)
325 (
327 .. [#WOT-STATS] WoT Node Stats
328 (
330 .. [#GLEP76] GLEP 76: Copyright Policy
331 (
333 .. [#XEP-0373] XEP-0373: OpenPGP for XMPP
334 (
336 .. [#KEYBASE.IO] Keybase
337 (
339 .. [#DEBIAN-IDENTIFICATION] Debian -- Step 2: Identification
340 (
342 .. [#NETBSD-PGP] PGP Key Management Guide for NetBSD developers
343 (
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
353 --
354 Best regards,
355 Michał Górny


File name MIME type
signature.asc application/pgp-signature