1 |
Hi, |
2 |
|
3 |
Following the replies to my earlier GLEP, I'd like to separately discuss |
4 |
introducing Authority Keys to provide validity proof for @gentoo.org |
5 |
UIDs. |
6 |
|
7 |
TL;DR: we'd create OpenPGP key that will be used to (semi-?) |
8 |
automatically sign @gentoo.org UIDs on developer keys (as listed |
9 |
in LDAP), so users could trust this key and have all developers verified |
10 |
instantly. |
11 |
|
12 |
|
13 |
Problem being solved: making it possible for users to easily verify |
14 |
developer keys and distinguish them from potential fraud. Since |
15 |
by definition Gentoo developers are people having access to Gentoo |
16 |
servers, it is reasonable to use the key fingerprints stored there |
17 |
as point of truth. |
18 |
|
19 |
This is somewhat already achieved by gentoo-keys seeds file. However, |
20 |
that file is entirely custom and it doesn't work out of the box outside |
21 |
gkeys environment. On the other hand, WoT-based validity checks are |
22 |
built-in in GnuPG and can be semi-reasonably used for this purpose. |
23 |
|
24 |
The generic idea is that we'd publish an 'Authority Key' with its |
25 |
fingerprint presented on the website along with service keys. We'd sign |
26 |
all @gentoo.org UIDs matching LDAP entries with this key and publish |
27 |
the signatures on keyservers. Then the user would fetch this authority |
28 |
key, verify its fingerprint, set it to full trust and WoT calculation |
29 |
would automatically result in all developer keys being trusted. |
30 |
|
31 |
Developer key revocation: having a single signing point also makes it |
32 |
easy to handle revocations (e.g. due to developers retiring). We would |
33 |
just have to revoke the relevant signatures, and publish updates. |
34 |
|
35 |
|
36 |
Authority Key protection: since keysigning is done using the primary |
37 |
key, it would have to be exposed to attacks. Unlike with subkeys, we |
38 |
would have to revoke the whole key in case of compromise. |
39 |
|
40 |
Therefore, I would like to propose creating two layers of Authority |
41 |
Keys: L1 and L2. The L1 key would be protected strongly and used only |
42 |
to sign L2 key. The L2 key would be used to sign actual keys. |
43 |
|
44 |
Users would only validate L1 key, and L2 would become valid implicitly. |
45 |
If L2 ever becomes compromised, we'd revoke it and use L1 to sign a new |
46 |
key. This way, GnuPG would appropriately stop trusting old L2 |
47 |
and verify new L2 as valid. |
48 |
|
49 |
|
50 |
Your comments? Anything I've missed? |
51 |
|
52 |
-- |
53 |
Best regards, |
54 |
Michał Górny |