1 |
On 2/17/19 7:54 PM, Matthew Thode wrote: |
2 |
> On 19-02-17 09:55:54, Michał Górny wrote: |
3 |
>> On Sun, 2019-02-17 at 06:56 +0000, Robin H. Johnson wrote: |
4 |
>>> On Sat, Feb 16, 2019 at 09:40:21AM +0100, Michał Górny wrote: |
5 |
>>> 2. The uid signatures should NOT be naively exported to keyservers. They |
6 |
>>> should use the CAFF method of generating a uid signature, writing it to a file, |
7 |
>>> and sending it as an encrypted message to the uid address. The uid owner is |
8 |
>>> responsible for decrypt + sending to servers. This ensures that the email |
9 |
>>> address and key are still tied together. |
10 |
>> That sounds like awful requirement of statefulness with requirement of |
11 |
>> manual manipulation to me, i.e. a can of worms. Do we really need to |
12 |
>> assume that Gentoo developers will be adding keys they can't use to |
13 |
>> LDAP? |
14 |
>> |
15 |
> It could also be a bad actor, though that comes with other concerns. |
16 |
> The CAFF method is the standard way of handling signatures, switching to |
17 |
> ldap also switches our trust store to be based on ldap, not developer |
18 |
> keys (anything can be in ldap). |
19 |
|
20 |
Different threat models, if you assume the malicious actor can edit the |
21 |
fingerprint in LDAP to begin with they have access to the email itself, |
22 |
and we control the email address since only the @gentoo.org UID is signed. |
23 |
|
24 |
-- |
25 |
Kristian Fiskerstrand |
26 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
27 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |