Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Cc: "Michał Górny" <mgorny@g.o>
Subject: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys
Date: Sun, 24 Feb 2019 14:14:08
1 ---
2 glep-9999.rst | 359 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 1 file changed, 359 insertions(+)
4 create mode 100644 glep-9999.rst
6 diff --git a/glep-9999.rst b/glep-9999.rst
7 new file mode 100644
8 index 0000000..d66398b
9 --- /dev/null
10 +++ b/glep-9999.rst
11 @@ -0,0 +1,359 @@
12 +---
13 +GLEP: 9999
14 +Title: Gentoo OpenPGP Authority Keys
15 +Author: Michał Górny <mgorny@g.o>
16 +Type: Standards Track
17 +Status: Draft
18 +Version: 1
19 +Created: 2019-02-24
20 +Last-Modified: 2019-02-24
21 +Post-History:
22 +Content-Type: text/x-rst
23 +Requires: 63
24 +---
25 +
26 +Abstract
27 +========
28 +This GLEP proposes using Authority Keys to provide developer key
29 +validity proofs that are compatible with web of trust. The signatures
30 +on ```` UIDs are automatically maintained, and user can
31 +follow the current set of valid keys by importing and trusting a single
32 +Authority Key. The system operates within standard features of GnuPG
33 +and requires only minimal setup from the user.
34 +
35 +
36 +Motivation
37 +==========
38 +All the recent efforts on improving OpenPGP usage in Gentoo were focused
39 +on internal usage and distribution. The existing policies and tooling
40 +are sufficient to account for verify specific usage, including commit
41 +signing (with both internal and user-oriented verification via custom
42 +tools) or release media verification. However, they do not provide
43 +for rapid OpenPGP deployment for secure communications usage.
44 +
45 +The Gentoo webservers distribute both convenient key bundles
46 +and individual keys via Web Key Directory. While in both cases
47 +the transfer is secured via HTTPS, providing authenticity verification
48 +via PKI/DNSSEC, those channels are meant to *distribute* the keys
49 +and not provide implicit guarantees on their *validity*. For example,
50 +they provide no guarantees that the user identifiers on the keys are
51 +legitimate. [#KEY-BUNDLES]_
52 +
53 +Internally, Gentoo's LDAP directory serves as the canonical source
54 +of information on key validity. It stores a list of key fingerprints
55 +for each Gentoo developers, and therefore allows the system to establish
56 +which keys are acceptable in context of a specific developer. However,
57 +the LDAP directory is not available to the public and therefore is only
58 +suitable for internal infrastructure use. [#LDAP-GUIDE]_
59 +
60 +The Gentoo website is focused on service keys and not individual
61 +developer keys. While it could easily be amended with full fingerprints
62 +of all developer keys, the necessity of manually verifying such a large
63 +number of keys would be inconvenient to the end user.
65 +
66 +The key package provided in the Gentoo repository is also focused
67 +on service keys, and has limited value in verifying key validity
68 +(currently, it assumes all UIDs on all keys in the keyring are valid).
69 +Providing a package with developer keys would both require frequent
70 +semi-manual updates, and establishing a more precise validity model.
72 +
73 +Gentoo-keys project provides so-called seed files that carry enough
74 +information to establish key validity, and are authenticated via HTTPS.
75 +However, they rely on installing custom software that does not integrate
76 +well with regular use of GnuPG e.g. in mail clients, and that is not
77 +easily usable in other systems. [#GENTOO-KEYS]_
78 +
79 +The Authority Key proposal aims to provide a more standard way of
80 +establishing validity of Gentoo developer keys. It builds upon the web
81 +of trust model, requiring no special software and minimal setup from end
82 +users.
83 +
84 +
85 +Specification
86 +=============
87 +Purpose and usage
88 +-----------------
89 +The purpose of the Authority Keys is to provide an automatically issued
90 +signatures on Gentoo developer OpenPGP keys, based on the information
91 +provided internally in the Gentoo LDAP directory. The service
92 +is provided for all active Gentoo developers, from the moment of their
93 +recruitment.
94 +
95 +Whenever a developer account is created, reactivated, renamed or has
96 +a new key fingerprint added, a signature is automatically created
97 +on the appropriate ```` UIDs and pushed to the keyservers.
98 +Whenever an old signature expires, a new one is automatically created.
99 +Whenever a developer account is disabled, renamed or has a fingerprint
100 +removed, the signatures from obsolete UIDs are automatically revoked.
101 +
102 +The signatures are issued only on the UIDs matching the Gentoo
103 +developer's ```` mailbox address, on keys whose primary key
104 +fingerprints are listed in Gentoo LDAP ``gpgfingerprint`` records. Keys
105 +missing such an UID are ignored. **Names on the relevant user
106 +identifiers are not verified**. The signatures are issued with
107 +an expiration date of 1 year from being issued.
108 +
109 +
110 +L1 and L2 keys
111 +--------------
112 +The Authority Keys are issued in two layers, appropriately called L1
113 +and L2.
114 +
115 +The single L1 Authority Key is used only to (manually) certify the L2
116 +Keys, and is kept securely offline following the Infrastructure policies
117 +on protecting primary keys. The fingerprint of this key is published
118 +on the Gentoo website and users are requested to sign this key to enable
119 +key validity via Authority Keys.
120 +
121 +The L2 Authority Keys are used directly to sign developer keys. Since
122 +they are used in an automated service, they are exposed to attacks.
123 +They are trust-signed by the L1 key and can be revoked and rotated more
124 +frequently than the L1 key.
125 +
126 +This dual-layer model aims to combine improved security with user
127 +convenience. While the individual Gentoo keys are signed by the L2 key,
128 +the users sign only the L1 key and the validity is established via chain
129 +L1 → L2 → developer key. This makes it possible to replace the L2 key
130 +if it ever becomes compromised without requiring the users to
131 +reestablish trust. Since the replacement key will be also signed
132 +by the L1 key (provided that it was not compromised), the validity
133 +of developer keys will remain established.
134 +
135 +
136 +Validating the L1 key
137 +---------------------
138 +Establishing the authenticity of the L1 Authority Key is essential
139 +to the system. Initially, the users will be able to determine
140 +the authenticity via comparing the key fingerprint with the one
141 +published on the website. This will shift the authenticity verification
143 +
144 +However, at the same time users are encouraged to sign the key upon
145 +verifying it. This will effectively make it possible to establish key's
146 +validity via OpenPGP web of trust.
147 +
148 +
149 +Rationale
150 +=========
151 +Authority Key model vs web of trust
152 +-----------------------------------
153 +The regular web of trust model relies on individuals verifying
154 +the Gentoo developer identity and access to the particular
155 +```` e-mail address. The particular UID is considered valid
156 +if a sufficient number of people trusted by the user in question have
157 +confirmed the developer's identity. This specifically relies on being
158 +able to establish a chain of trust between the developer and user.
159 +
160 +At the moment, many of the existing Gentoo developers did not even
161 +stablish a chain of trust between one another, not to mention establish
162 +web of trust coverage that would make it feasible for users to reach any
163 +specific developer. Efforts towards improving that were rejected
164 +by the developers, mostly based on argumentation that many developers
165 +find it impossible to meet any other community member for the purpose
166 +of identity verification.
167 +
168 +The Authority Key model, on the other hand, assumes that there is
169 +a single trusted authority that verifies Gentoo developers' keys.
170 +The user verifies the key representing this authority and trusts it.
171 +The validity of keys used by all developers is established via a single
172 +point of trust.
173 +
174 +The procedure of establishing the validity of a specific key does not
175 +involve the necessity of meeting anyone or verifying identity. While
176 +the validity is exposed in a manner compatible with web of trust, it is
177 +verified against LDAP which implicitly proves authenticity of the keys.
178 +
179 +Therefore, the Authority Key model is much easier to set up. The user
180 +merely needs to verify a single key and trust it, while pure WoT would
181 +probably require trusting multiple third party identities. It is also
182 +more secure as it limits the attack vector to a single key rather than
183 +one of potentially large number of keys that need to be trusted by
184 +the user. If the user decides to stop trusting ```` UIDs,
185 +the validity can easily be reverted by disabling the single Authority
186 +Key.
187 +
188 +
189 +Authority Key vs gentoo-keys
190 +----------------------------
191 +The gentoo-keys project provides seed data that is sufficient to verify
192 +the authenticity of the keys. However, this data uses entirely custom
193 +format and therefore requires special tooling to process. This tooling
194 +has not been packaged for any other Linux distribution or operating
195 +system, and is non-trivial to install as unprivileged user.
196 +
197 +The Authority Key model is based entirely on built-in GnuPG features.
198 +It does not require any special tooling to run. The necessary bootstrap
199 +can be done manually via GnuPG command-line facilities. Eventually,
200 +even that may become unnecessary if the Authority Key is covered via
201 +web of trust.
202 +
203 +Furthermore, gentoo-keys seed data currently requires manual updates.
204 +The Authority Key system is automated, and therefore subject to smaller
205 +delays in operation.
206 +
207 +
208 +Developer coverage
209 +------------------
210 +In the original proposal, it was debated whether new developers should
211 +be subject to grace period during which their keys would not be signed.
212 +However, no arguments were brought to support such a period,
213 +and therefore the GLEP assumes all developers are covered as long
214 +as they are considered active Gentoo developers.
215 +
216 +Since only ```` e-mail addresses are under Gentoo control
217 +and developer identities outside the distribution are outside the scope
218 +of this project, only UIDs matching the respective developer addresses
219 +are signed. This is meant to prevent the developers from forging
220 +somebody else's identity.
221 +
222 +The developers' real names are not verified. Firstly, the purpose
223 +of this project is to establish association between keys and specific
224 +Gentoo developers, whose primary identification is the nickname used
225 +in Gentoo. The exact real name is irrelevant to the validity in this
226 +context. Secondly, comparing real names between LDAP and user
227 +identifiers would be non-trivial and most likely cause a number of
228 +developers being silently rejected due to e.g. modified name spelling.
229 +
230 +
231 +caff verification model
232 +-----------------------
233 +During the initial debate, using a model similar to Debian's caff tool
234 +was suggested. In this model, new signatures are sent encrypted
235 +to the developers rather than uploaded straight to keyservers.
236 +Developers need to decrypt and add them to their keys themselves.
237 +[#CAFF]_
238 +
239 +The main purpose of the caff model is to assist users in verifying
240 +e-mail addresses of the UIDs they are about to sign. By sending
241 +an encrypted e-mail, this model verifies that the recipient is both
242 +able to receive mail at a specific address and decrypt messages
243 +encrypted using the specified key. Since the message contains complete
244 +signature ready to be imported, the key signing process can be completed
245 +entirely by the recipient and the sender does not need to be concerned
246 +past sending it.
247 +
248 +However, there seems to be no clear reason to employ this model here.
249 +A reasonable assumption can be made that if one is able to access
250 +the LDAP directory as a particular Gentoo developer, one is also able
251 +to access the developer's mailbox. This considered, verifying
252 +the e-mail address in caff fashion is redundant.
253 +
254 +Furthermore, implementing this model increases complexity both server-
255 +and client-side. The server would need to be entirely stateful to avoid
256 +sending duplicate mails, and at the same time it would need to permit
257 +re-requesting signature e-mails. The developers would need to manually
258 +import the signature and send it to keyservers.
259 +
260 +It is quite probable that some of the less active developers would be
261 +permanently excluded by being unaware or uninterested in participating
262 +in the new system. Furthermore, signature expirations would cause
263 +potentially extensive periods of key invalidity to occur (between
264 +signature expiration and import of the new one). During those periods,
265 +users' ability to mail developers securely would be hindered.
266 +
267 +
268 +Dual-layer model
269 +----------------
270 +The dual-layer Authority Key model is established in order to combine
271 +security with needed automation. The L1 Key provides higher level
272 +of security, at the cost of requiring manual operation. The L2 Keys are
273 +suitable for automated use but that implies they're exposed to attacks.
274 +
275 +If the model was based on a single key and that key was compromised,
276 +the key would have to be revoked and replaced with a new one. All users
277 +would have to fetch the new key and validate it independently to restore
278 +the developer key validity.
279 +
280 +Using two keys introduces a middle link in the trust chain that can be
281 +replaced easily. Users trust the L1 Key which is unlikely to be
282 +compromised. The trust on L2 Key is implicitly provided by the L1 Key,
283 +and users do not need to be specifically concerned about it. If L2 Key
284 +is compromised, the Infrastructure developers can replace it and restore
285 +the trust via (non-compromised) L1 Key. Users only have to fetch
286 +the new key and validity is restored.
287 +
288 +
289 +Security considerations
290 +-----------------------
291 +The user needs to be able to verify the authenticity of the L1 Key.
292 +This can be done in one of two ways:
293 +
294 +a. via comparing the fingerprint against the record on Gentoo website.
295 + This relies on the security of Gentoo web servers, and the website
296 + content repository. From user side, authenticity relies on PKI
297 + and/or DNSSEC, and possibly any other future HTTPS protection
298 + mechanisms.
299 +
300 +b. via web of trust, provided the user trusts someone who verified
301 + the key first. In this case, the authenticity relies entirely
302 + on the web of trust model, and is subject to attacks specific to it
303 + (e.g. to wrongly trusting a malicious person).
304 +
305 +The L1 Key itself is protected from being compromised via current
306 +Infrastructure best practices. At this moment, this involves password
307 +protection and offline storage. If the key ever becomes compromised,
308 +the procedures involve revoking it and announcing the problem.
309 +
310 +The L2 Keys lack this kind of protection by design. If they become
311 +compromised, the procedure involves revoking the key quickly
312 +and replacing it with a new one.
313 +
314 +In both cases, the revocation procedure relies on the user periodically
315 +refreshing keys against reliable sources. Typically this involves using
316 +SKS keyservers over HKPS which in turn relies on PKI to prevent a third
317 +party from intercepting propagation of revocations.
318 +
319 +The validity of developer key UIDs is established via signatures made
320 +by the L2 Key. If UIDs become no longer valid, the signatures are
321 +revoked in order to invalidate them. This also relies on users
322 +periodically pulling keyservers for developer key updates.
323 +
324 +Additionally, signatures are made with one year expiration time.
325 +In the extremely unlikely case of scripts failing to revoke
326 +the particular signature, it will expire automatically.
327 +
328 +
329 +Backwards Compatibility
330 +=======================
331 +This proposal is established independently of existing solutions,
332 +and does not affect them.
333 +
334 +
335 +Reference Implementation
336 +========================
337 +The reference tooling for maintaining Authority Key signatures is
338 +published as gentoo-authority-key project. [#GENTOO-AUTHORITY-KEY]_
339 +
340 +
341 +References
342 +==========
343 +.. [#KEY-BUNDLES] Directory listing including .gpg key bundles
344 + (
345 +
346 +.. [#LDAP-GUIDE] Project:Infrastructure/LDAP Guide - Gentoo Wiki
347 + (
348 +
349 +.. [#WWW-SIGNATURES] Release media signatures - Gentoo Linux
350 + (
351 +
352 +.. [#KEY-PACKAGE] app-crypt/openpgp-keys-gentoo-release – Gentoo Packages
353 + (
354 +
355 +.. [#GENTOO-KEYS] Project:Gentoo-keys - Gentoo Wiki
356 + (
357 +
358 +.. [#CAFF] caff - Debian Wiki
359 + (
360 +
361 +.. [#GENTOO-AUTHORITY-KEY] mgorny/gentoo-authority-key: Script to
362 + automatically sign developer keys using OpenPGP authority key
363 + (
364 +
365 +
366 +Copyright
367 +=========
368 +This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
369 +Unported License. To view a copy of this license, visit
370 +
371 --
372 2.21.0.rc2