1 |
Hi, |
2 |
|
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. |
5 |
|
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. |
10 |
|
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. |
16 |
|
17 |
The text below. |
18 |
|
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 |
--- |
33 |
|
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. |
43 |
|
44 |
|
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]_ |
52 |
|
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. |
60 |
|
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. |
64 |
|
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. |
69 |
|
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. |
75 |
|
76 |
|
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. |
86 |
|
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). |
96 |
|
97 |
|
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: |
104 |
|
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. |
108 |
|
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: |
112 |
|
113 |
a. Verifying that the counter-forgery features of the verified |
114 |
document are present and are correct. |
115 |
|
116 |
b. Verifying that the signee's face resembles the photograph |
117 |
on the document. |
118 |
|
119 |
c. Verifying that the signee is able to issue a signature similar |
120 |
to the one on the document (if present). |
121 |
|
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. |
126 |
|
127 |
Only once all three factors are positively verified may the particular |
128 |
UID be signed according to this policy. |
129 |
|
130 |
|
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. |
137 |
|
138 |
|
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.: |
145 |
|
146 |
- public notaries, |
147 |
|
148 |
- government identity services (provided that the signer is able to |
149 |
obtain a cryptographically secured proof of identity), |
150 |
|
151 |
- bank wire transfers. |
152 |
|
153 |
|
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]_ |
163 |
|
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. |
168 |
|
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. |
176 |
|
177 |
|
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. |
184 |
|
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. |
189 |
|
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. |
197 |
|
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. |
204 |
|
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]_ |
210 |
|
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. |
216 |
|
217 |
|
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. |
223 |
|
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. |
228 |
|
229 |
|
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. |
237 |
|
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. |
241 |
|
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. |
245 |
|
246 |
|
247 |
Backwards Compatibility |
248 |
======================= |
249 |
The policy is non-obligatory, and therefore does not affect existing |
250 |
developers. |
251 |
|
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. |
255 |
|
256 |
|
257 |
Reference Implementation |
258 |
======================== |
259 |
n/a |
260 |
|
261 |
|
262 |
References |
263 |
========== |
264 |
.. [#GLEP76] GLEP 76: Copyright Policy |
265 |
(https://www.gentoo.org/glep/glep-0076.html) |
266 |
|
267 |
.. [#WOT-JAN2019] [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust |
268 |
(https://archives.gentoo.org/gentoo-project/message/d05ae93cac6fbac0eea07fc597519382) |
269 |
|
270 |
.. [#CAFF] caff - Debian Wiki |
271 |
(https://wiki.debian.org/caff) |
272 |
|
273 |
|
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 |
278 |
http://creativecommons.org/licenses/by-sa/3.0/. |
279 |
|
280 |
|
281 |
-- |
282 |
Best regards, |
283 |
Michał Górny |