Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] [RFC pre-GLEP] Identity verification via OpenPGP WoT
Date: Mon, 04 Mar 2019 19:07:14
1 Hi,
3 Here's a revival of WoT pre-GLEP. I've followed the earlier
4 suggestions, and rewritten it from scratch with a different perspective.
6 Unlike the previous proposal, this one is focused entirely on providing
7 a distributed identity verification method, with OpenPGP key signatures
8 being used as a technical means for storing the verification result.
9 The construction of WoT is merely a side effect.
11 The GLEP itself does not enforce signing in any circumstances. It could
12 be useful e.g. when developers have reasons not to believe in proxy-
13 maintainers' identities, and need some proof. I also recommend
14 enforcing it e.g. inside Infra project but GLEP leaves that for
15 a separate policy.
17 The text below.
19 ---
20 GLEP: 9999
21 Title: Identity verification via OpenPGP WoT
22 Author: Michał Górny <mgorny@g.o>
23 Type: Standards Track
24 Status: Draft
25 Version: 1
26 Created: 2019-03-04
27 Last-Modified: 2019-03-04
28 Post-History: 2019-03-04
29 Content-Type: text/x-rst
30 Requires:
31 Replaces:
32 ---
34 Abstract
35 ========
36 This GLEP proposes establishing a non-obligatory, distributed identity
37 verification procedure that is compatible with OpenPGP web of trust. It
38 could be used whenever an explicit need for verifying the real name
39 occurs, enforced on groups of developers with elevated privileges
40 via a separate policy or serve as guidelines for building web of trust.
41 Three methods of verifying the identity are proposed: face-to-face,
42 via webcam or via government-controlled identification services.
45 Motivation
46 ==========
47 GLEP 76 (Copyright Policy) specifies that all commits made to Gentoo
48 repositories must include a sign-off with a person's real name.
49 However, it does not specify any particular method of verifying it.
50 It is a standing policy that it is sufficient for contributor to
51 acknowledge the legitimacy of the provided name. [#GLEP76]_
53 At the same time, developers are asked not to accept contributions
54 if they have justified concerns as to the authenticity of the name
55 provided. In particular, this could happen if the developer happens
56 to know the contributor personally, the contributor indicated that he
57 is using a pseudonym or arbitrarily changed his name under the policy.
58 In this case, we lack a clear policy allowing the contributor
59 to reattain trust.
61 Furthermore, enforcing higher standards for identity verification may
62 make sense for groups having elevated privileges or specific legal
63 responsibility, e.g. the Infrastructure team or Trustees.
65 If a centralized identity verification model was to be introduced
66 in Gentoo, it would probably be necessary to perform most
67 of the verifications remotely. This would require transferring
68 sensitive personal data to a single entity which is undesirable.
70 On the other hand, a distributed identity verification model is readily
71 provided by OpenPGP Web of Trust. In this case, verification can be
72 performed between individual pairs of developers, reducing the amount of
73 sensitive information at the disposal of a single entity and increasing
74 the chances of performing the verification face-to-face.
77 Specification
78 =============
79 Purpose and scope
80 -----------------
81 This specification does not enforce identity verification anywhere.
82 Instead, it aims to provide clear rules for whenever developers
83 establish such a process is necessary. Identity verification may be
84 enforced in specific groups of developers separately, via internal
85 project policies or Council-approved policies.
87 If a identity is verified according to this specification, this fact
88 should be recorded via signing UIDs matching the verified data
89 on the person's OpenPGP key. Such signature cryptographically confirms
90 that the signer has verified that the specific signee's UID provides
91 legitimate real name and e-mail address of the key owner. Furthermore,
92 it is recommended that the signer includes the URL of this GLEP
93 as the certification policy URL (``--cert-policy-url`` in GnuPG),
94 and appropriately indicates certification level (see
95 ``--default-cert-level`` in GnuPG).
98 Identity verification
99 ---------------------
100 Face-to-face verification
101 ~~~~~~~~~~~~~~~~~~~~~~~~~
102 The recommended procedure for identity verification is for the signer
103 to meet signee face-to-face. The signer must:
105 1. Obtain a hardcopy of signee's OpenPGP key fingerprint. The signer
106 must afterwards use the fingerprint to verify the authenticity
107 of the key being used.
109 2. Verify the signee's identity using a government-issued identification
110 document with a photograph. The verification must include,
111 to the best of signer's abilities:
113 a. Verifying that the counter-forgery features of the verified
114 document are present and are correct.
116 b. Verifying that the signee's face resembles the photograph
117 on the document.
119 c. Verifying that the signee is able to issue a signature similar
120 to the one on the document (if present).
122 3. Verify the signee's e-mail address(es), through sending an e-mail
123 encrypted using signee's OpenPGP key, containing either randomly
124 generated data, or an exported signature for the UID in question.
125 Each mail sent must contain unique data.
127 Only once all three factors are positively verified may the particular
128 UID be signed according to this policy.
131 Remote webcam verification
132 ~~~~~~~~~~~~~~~~~~~~~~~~~~
133 Alternatively to face-to-face verification, it is acceptable to perform
134 the verification using high-resolution real-time video stream. In this
135 case, the signee should perform all the actions necessary for the signer
136 to be able to verify the identity document in front of the camera.
139 Verification via government identity services
140 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
141 Finally, it is acceptable to use one of the identity proof forms that
142 are considered legally meaningful in a particular country, and guarantee
143 the signee's identity has been verified by an official. This could
144 include e.g.:
146 - public notaries,
148 - government identity services (provided that the signer is able to
149 obtain a cryptographically secured proof of identity),
151 - bank wire transfers.
154 Rationale
155 =========
156 Non-obligatory nature
157 ---------------------
158 The previous WoT proposal made signatures obligatory. This has met with
159 resistance of developers, including claims that there are individuals
160 within Gentoo who are unable to get their key signed using any of
161 the proposed methods and outright rejection of real name verification.
162 [#WOT-JAN2019]_
164 Therefore, this proposal avoids making keysigning obligatory for
165 everyone. However, it does aim to provide official rule set for
166 keysigning that can be used by developers at their discretion, or
167 whenever there is a valid need of verifying contributor's identity.
169 The GLEP also makes provisions for enforcing identity verification
170 separately, as a matter of policy. While it could propose establishing
171 such a policy for particular projects such as Infra, it makes little
172 sense to maintain a list of such projects in a GLEP, and update it
173 whenever it changes. Instead, individual projects can enforce name
174 verification on their members, or Council can enforce wider policies
175 if there is an agreement on them.
178 Face-to-face verification rules
179 -------------------------------
180 The verification rules follow common keysigning practices. Notably,
181 they are based on assumption that a single signature confirms
182 the combination of three elements: the signee's primary key, real name
183 and an e-mail address.
185 Verifying the primary key fingerprint is important to ensure that
186 the authentic key belonging to the signee is being used. Otherwise,
187 a malicious third party could create a key with matching UID and signer
188 could sign it instead of the authentic key.
190 Verifying the real name is the specific purpose of this GLEP, as well
191 as a standard practice for OpenPGP web of trust. The name should be
192 verified against documents that are expectedly hard to forge, and that
193 include photograph that could be used to verify the owner. Since
194 photograph verification is non-trivial and in some cases documents
195 contain outdated photos, it is supplemented with signature verification
196 whenever possible. In any case, this part is considered best effort.
198 Verifying the e-mail address is necessary since OpenPGP does not provide
199 any proof of address ownership, and arbitrary user identifiers can be
200 added to a key. Unique data needs to be used in order to verify each
201 address separately. The data is encrypted to additionally confirm
202 that the e-mail address' owner actually has access to the key,
203 and to avoid accidental mistakes.
205 Traditionally, it is considered sufficient to export a signature for
206 each e-mail address, and send it. Then, the signee can decrypt it,
207 import and publish the update to his key afterwards without
208 the necessity of any further action from the signer. Doing this
209 manually is non-trivial; the caff tool can help. [#CAFF]_
211 Alternatively, a simple encrypted e-mail exchange with random data
212 can be used instead. Afterwards, the signer signs all confirmed UIDs
213 and publishes the signature. This method does not require special
214 tooling and has the additional advantage of verifying that the signee
215 can send mail from claimed address.
218 Allowing webcam identification
219 ------------------------------
220 There are conflicting opinions as to whether remote identity
221 verification is valid. However, this method can prove helpful whenever
222 the signee does not live near any developer.
224 The use of live, high-resolution stream aims to both reduce the risk of
225 forgery and copying signee's identification documents. The ability to
226 move freely is also necessary to provide at least partial verification
227 of counter-forgery measures.
230 Allowing government identification services
231 -------------------------------------------
232 Finally, whenever direct verification is inconvenient, it could be
233 acceptable to rely on government officials and institutions that are
234 expected to verify the identity of citizens. The most common case of
235 this are public notaries who can provide appropriate proofs of identity
236 for a fee.
238 Besides those, if the signer and signee live in the same country,
239 additional national verification mechanisms may be used as long
240 as special care is taken to perform an authenticated exchange.
242 In some cases, randomly-generated data exchange via wire transfer may be
243 considered sufficient, provided that the signee's bank is known to
244 verify identity of its customers.
247 Backwards Compatibility
248 =======================
249 The policy is non-obligatory, and therefore does not affect existing
250 developers.
252 Existing developer signatures may be incompatible with the policy.
253 In order to make policy conformance clear, the GLEP recommends including
254 appropriate policy URL in signatures.
257 Reference Implementation
258 ========================
259 n/a
262 References
263 ==========
264 .. [#GLEP76] GLEP 76: Copyright Policy
265 (
267 .. [#WOT-JAN2019] [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust
268 (
270 .. [#CAFF] caff - Debian Wiki
271 (
274 Copyright
275 =========
276 This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
277 Unported License. To view a copy of this license, visit
281 --
282 Best regards,
283 Michał Górny


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