Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys
Date: Sat, 16 Feb 2019 08:40:29
Message-Id: 1550306421.831.16.camel@gentoo.org
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

Attachments

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

Replies