1 |
Hi, |
2 |
|
3 |
Here's -r1. Changes: |
4 |
|
5 |
- Included more explanation of cert levels. |
6 |
|
7 |
- Allowed more secure forms of key verification than fingerprint (after |
8 |
all, fingerprint is SHA-1 of key material). |
9 |
|
10 |
- Allowed any secure channel for key exchange, with paper staying |
11 |
the recommendation. |
12 |
|
13 |
- Added a section with command-line options matching the spec. |
14 |
|
15 |
--- |
16 |
GLEP: 9999 |
17 |
Title: Identity verification via OpenPGP WoT |
18 |
Author: Michał Górny <mgorny@g.o> |
19 |
Type: Standards Track |
20 |
Status: Draft |
21 |
Version: 1 |
22 |
Created: 2019-03-04 |
23 |
Last-Modified: 2019-03-05 |
24 |
Post-History: 2019-03-04 |
25 |
Content-Type: text/x-rst |
26 |
Requires: |
27 |
Replaces: |
28 |
--- |
29 |
|
30 |
Abstract |
31 |
======== |
32 |
This GLEP proposes establishing a non-obligatory, distributed identity |
33 |
verification procedure that is compatible with OpenPGP web of trust. It |
34 |
could be used whenever an explicit need for verifying the real name |
35 |
occurs, enforced on groups of developers with elevated privileges |
36 |
via a separate policy or serve as guidelines for building web of trust. |
37 |
Three methods of verifying the identity are proposed: face-to-face, |
38 |
via webcam or via government-controlled identification services. |
39 |
|
40 |
|
41 |
Motivation |
42 |
========== |
43 |
GLEP 76 (Copyright Policy) specifies that all commits made to Gentoo |
44 |
repositories must include a sign-off with a person's real name. |
45 |
However, it does not specify any particular method of verifying it. |
46 |
It is a standing policy that it is sufficient for contributor to |
47 |
acknowledge the legitimacy of the provided name. [#GLEP76]_ |
48 |
|
49 |
At the same time, developers are asked not to accept contributions |
50 |
if they have justified concerns as to the authenticity of the name |
51 |
provided. In particular, this could happen if the developer happens |
52 |
to know the contributor personally, the contributor indicated that he |
53 |
is using a pseudonym or arbitrarily changed his name under the policy. |
54 |
In this case, we lack a clear policy allowing the contributor |
55 |
to reattain trust. |
56 |
|
57 |
Furthermore, enforcing higher standards for identity verification may |
58 |
make sense for groups having elevated privileges or specific legal |
59 |
responsibility, e.g. the Infrastructure team or Trustees. |
60 |
|
61 |
If a centralized identity verification model was to be introduced |
62 |
in Gentoo, it would probably be necessary to perform most |
63 |
of the verifications remotely. This would require transferring |
64 |
sensitive personal data to a single entity which is undesirable. |
65 |
|
66 |
On the other hand, a distributed identity verification model is readily |
67 |
provided by OpenPGP Web of Trust. In this case, verification can be |
68 |
performed between individual pairs of developers, reducing the amount of |
69 |
sensitive information at the disposal of a single entity and increasing |
70 |
the chances of performing the verification face-to-face. |
71 |
|
72 |
|
73 |
Specification |
74 |
============= |
75 |
Purpose and scope |
76 |
----------------- |
77 |
This specification does not enforce identity verification anywhere. |
78 |
Instead, it aims to provide clear rules for whenever developers |
79 |
establish such a process is necessary. Identity verification may be |
80 |
enforced in specific groups of developers separately, via internal |
81 |
project policies or Council-approved policies. |
82 |
|
83 |
If a identity is verified according to this specification, this fact |
84 |
should be recorded via signing UIDs matching the verified data |
85 |
on the person's OpenPGP key. Such signature cryptographically confirms |
86 |
that the signer has verified that the specific signee's UID provides |
87 |
legitimate real name and e-mail address of the key owner. Furthermore, |
88 |
it is recommended that the signer includes the URL of this GLEP |
89 |
as the certification policy URL (``--cert-policy-url`` in *gpg(1)*), |
90 |
and appropriately indicates certification level (see |
91 |
``--default-cert-level`` in *gpg(1)*). |
92 |
|
93 |
The certification level of signatures following this specification must |
94 |
be either 2 or 3, depending on how minutely the signer verified signee's |
95 |
identification documents. |
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 the signee's OpenPGP key fingerprint, the complete public key |
106 |
data or a stronger digest of it over a tamper-resistant channel |
107 |
(preferably on paper). The signer must reliably compare this data to |
108 |
verify the authenticity of the key being signed. |
109 |
|
110 |
2. Verify the signee's identity using a government-issued identification |
111 |
document with a photograph. The verification must include, |
112 |
to the best of signer's abilities: |
113 |
|
114 |
a. Verifying that the counter-forgery features of the verified |
115 |
document are present and are correct. |
116 |
|
117 |
b. Verifying that the signee's face resembles the photograph |
118 |
on the document. |
119 |
|
120 |
c. Verifying that the signee is able to issue a signature similar |
121 |
to the one on the document (if present). |
122 |
|
123 |
3. Verify the signee's e-mail address(es), through sending an e-mail |
124 |
encrypted using signee's OpenPGP key, containing either randomly |
125 |
generated data, or an exported signature for the UID in question. |
126 |
Each mail sent must contain unique data. |
127 |
|
128 |
Only once all three factors are positively verified may the particular |
129 |
UID be signed according to this policy. |
130 |
|
131 |
|
132 |
Remote webcam verification |
133 |
~~~~~~~~~~~~~~~~~~~~~~~~~~ |
134 |
Alternatively to face-to-face verification, it is acceptable to perform |
135 |
the verification using high-resolution real-time video stream. In this |
136 |
case, the signee should perform all the actions necessary for the signer |
137 |
to be able to verify the identity document in front of the camera. |
138 |
|
139 |
|
140 |
Verification via government identity services |
141 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
142 |
Finally, it is acceptable to use one of the identity proof forms that |
143 |
are considered legally meaningful in a particular country, and guarantee |
144 |
the signee's identity has been verified by an official. This could |
145 |
include e.g.: |
146 |
|
147 |
- public notaries, |
148 |
|
149 |
- government identity services (provided that the signer is able to |
150 |
obtain a cryptographically secured proof of identity), |
151 |
|
152 |
- bank wire transfers. |
153 |
|
154 |
|
155 |
GnuPG command line (informational) |
156 |
---------------------------------- |
157 |
In order to create a signature following this specification, |
158 |
the following command-line arguments can be used:: |
159 |
|
160 |
gpg --cert-policy-url 'https://www.gentoo.org/glep/glep-9999.rst' \ |
161 |
--ask-cert-level --cert-digest-algo SHA512 \ |
162 |
--edit-key <key-fingerprint> |
163 |
|
164 |
Alternatively, if those options should bapply to all certifications |
165 |
made, they can be included in the configuration file |
166 |
``~/.gnupg/gpg.conf``:: |
167 |
|
168 |
cert-policy-url https://www.gentoo.org/glep/glep-9999.rst |
169 |
ask-cert-level |
170 |
cert-digest-algo SHA512 |
171 |
|
172 |
.. TODO: update URL when number is assigned |
173 |
|
174 |
``cert-policy-url`` specifies the policy to which the certification |
175 |
complies (as recommended above). ``ask-cert-level`` requests GnuPG |
176 |
to query certification level interactively when signing every key. |
177 |
``cert-digest-algo`` enables stronger SHA-2 512-bit digests |
178 |
on certifications. |
179 |
|
180 |
|
181 |
Rationale |
182 |
========= |
183 |
Non-obligatory nature |
184 |
--------------------- |
185 |
The previous WoT proposal made signatures obligatory. This has met with |
186 |
resistance of developers, including claims that there are individuals |
187 |
within Gentoo who are unable to get their key signed using any of |
188 |
the proposed methods and outright rejection of real name verification. |
189 |
[#WOT-JAN2019]_ |
190 |
|
191 |
Therefore, this proposal avoids making keysigning obligatory for |
192 |
everyone. However, it does aim to provide official rule set for |
193 |
keysigning that can be used by developers at their discretion, or |
194 |
whenever there is a valid need of verifying contributor's identity. |
195 |
|
196 |
The GLEP also makes provisions for enforcing identity verification |
197 |
separately, as a matter of policy. While it could propose establishing |
198 |
such a policy for particular projects such as Infra, it makes little |
199 |
sense to maintain a list of such projects in a GLEP, and update it |
200 |
whenever it changes. Instead, individual projects can enforce name |
201 |
verification on their members, or Council can enforce wider policies |
202 |
if there is an agreement on them. |
203 |
|
204 |
|
205 |
Face-to-face verification rules |
206 |
------------------------------- |
207 |
The verification rules follow common keysigning practices. Notably, |
208 |
they are based on assumption that a single signature confirms |
209 |
the combination of three elements: the signee's primary key, real name |
210 |
and an e-mail address. |
211 |
|
212 |
Verifying the primary key fingerprint is important to ensure that |
213 |
the authentic key belonging to the signee is being used. Otherwise, |
214 |
a malicious third party could create a key with matching UID and signer |
215 |
could sign it instead of the authentic key. |
216 |
|
217 |
Verifying the real name is the specific purpose of this GLEP, as well |
218 |
as a standard practice for OpenPGP web of trust. The name should be |
219 |
verified against documents that are expectedly hard to forge, and that |
220 |
include photograph that could be used to verify the owner. Since |
221 |
photograph verification is non-trivial and in some cases documents |
222 |
contain outdated photos, it is supplemented with signature verification |
223 |
whenever possible. In any case, this part is considered best effort. |
224 |
|
225 |
Verifying the e-mail address is necessary since OpenPGP does not provide |
226 |
any proof of address ownership, and arbitrary user identifiers can be |
227 |
added to a key. Unique data needs to be used in order to verify each |
228 |
address separately. The data is encrypted to additionally confirm |
229 |
that the e-mail address' owner actually has access to the key, |
230 |
and to avoid accidental mistakes. |
231 |
|
232 |
Traditionally, it is considered sufficient to export a signature for |
233 |
each e-mail address, and send it. Then, the signee can decrypt it, |
234 |
import and publish the update to his key afterwards without |
235 |
the necessity of any further action from the signer. Doing this |
236 |
manually is non-trivial; the caff tool can help. [#CAFF]_ |
237 |
|
238 |
Alternatively, a simple encrypted e-mail exchange with random data |
239 |
can be used instead. Afterwards, the signer signs all confirmed UIDs |
240 |
and publishes the signature. This method does not require special |
241 |
tooling and has the additional advantage of verifying that the signee |
242 |
can send mail from claimed address. |
243 |
|
244 |
|
245 |
Allowing webcam identification |
246 |
------------------------------ |
247 |
There are conflicting opinions as to whether remote identity |
248 |
verification is valid. However, this method can prove helpful whenever |
249 |
the signee does not live near any developer. |
250 |
|
251 |
The use of live, high-resolution stream aims to both reduce the risk of |
252 |
forgery and copying signee's identification documents. The ability to |
253 |
move freely is also necessary to provide at least partial verification |
254 |
of counter-forgery measures. |
255 |
|
256 |
|
257 |
Allowing government identification services |
258 |
------------------------------------------- |
259 |
Finally, whenever direct verification is inconvenient, it could be |
260 |
acceptable to rely on government officials and institutions that are |
261 |
expected to verify the identity of citizens. The most common case of |
262 |
this are public notaries who can provide appropriate proofs of identity |
263 |
for a fee. |
264 |
|
265 |
Besides those, if the signer and signee live in the same country, |
266 |
additional national verification mechanisms may be used as long |
267 |
as special care is taken to perform an authenticated exchange. |
268 |
|
269 |
In some cases, randomly-generated data exchange via wire transfer may be |
270 |
considered sufficient, provided that the signee's bank is known to |
271 |
verify identity of its customers. |
272 |
|
273 |
|
274 |
Backwards Compatibility |
275 |
======================= |
276 |
The policy is non-obligatory, and therefore does not affect existing |
277 |
developers. |
278 |
|
279 |
Existing developer signatures may be incompatible with the policy. |
280 |
In order to make policy conformance clear, the GLEP recommends including |
281 |
appropriate policy URL in signatures. |
282 |
|
283 |
|
284 |
Reference Implementation |
285 |
======================== |
286 |
n/a |
287 |
|
288 |
|
289 |
References |
290 |
========== |
291 |
.. [#GLEP76] GLEP 76: Copyright Policy |
292 |
(https://www.gentoo.org/glep/glep-0076.html) |
293 |
|
294 |
.. [#WOT-JAN2019] [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust |
295 |
(https://archives.gentoo.org/gentoo-project/message/d05ae93cac6fbac0eea07fc597519382) |
296 |
|
297 |
.. [#CAFF] caff - Debian Wiki |
298 |
(https://wiki.debian.org/caff) |
299 |
|
300 |
|
301 |
Copyright |
302 |
========= |
303 |
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 |
304 |
Unported License. To view a copy of this license, visit |
305 |
http://creativecommons.org/licenses/by-sa/3.0/. |
306 |
|
307 |
|
308 |
-- |
309 |
Best regards, |
310 |
Michał Górny |