Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys

[Michał Górny]

On Sun, 2019-02-17 at 12:54 -0600, Matthew Thode wrote:
> On 19-02-17 09:55:54, Michał Górny wrote:
> > On Sun, 2019-02-17 at 06:56 +0000, Robin H. Johnson wrote:
> > > On Sat, Feb 16, 2019 at 09:40:21AM +0100, Michał Górny wrote:
> > > 2. The uid signatures should NOT be naively exported to keyservers. They
> > > should use the CAFF method of generating a uid signature, writing it to a file,
> > > and sending it as an encrypted message to the uid address. The uid owner is
> > > responsible for decrypt + sending to servers. This ensures that the email
> > > address and key are still tied together.
> >
> > That sounds like awful requirement of statefulness with requirement of
> > manual manipulation to me, i.e. a can of worms.  Do we really need to
> > assume that Gentoo developers will be adding keys they can't use to
> > LDAP?
> >
>
> It could also be a bad actor, though that comes with other concerns.
> The CAFF method is the standard way of handling signatures, switching to
> ldap also switches our trust store to be based on ldap, not developer
> keys (anything can be in ldap).
>

As Kristian named it, could you please explain to me what specific
threat model does this address?

AFAIU the main purpose of the caff model is to verify that the person
whose key you are signing can access the particular e-mail address. 
Which certainly makes sense when you are signing an arbitrary key. 
However, I don't really see how that's relevant here, and I'd rather
not add needless complexity based on cargo cult imitation of caff.

In our case, the key fingerprint comes from LDAP, and is directly bound
to the particular username, therefore mailbox.  I don't really see it
a likely case that someone would be able to edit developer's LDAP
attributes but at the same time be unable to access his mailbox.

In other words, as I see it, the caff model can help if:

1) someone manages to compromise LDAP without compromising e-mail
service,

2) a developer accidentally puts the wrong fingerprint in LDAP,

3) a developer has broken e-mail setup,

4) a developer is inactive.

I think cases 1)-3) are rather unlikely, and 2)-3) belong to
the 'wrong place to solve the problem' category.  4) practically relies
on making an assumption that we don't want users to trust developers who
aren't active enough to add this signature.

The other side of this is added complexity on the scripting side, for
a start.  We need to store to whom we sent signatures to avoid resending
them over and over again.  Then, we need to able to force resending if
the developer lost the mail for some reason.

Finally, there will be at least a few developers who won't be covered by
this because they won't care enough to add the signature to their key.

My original goal was to cover all active developers because users might
have their reasons to contact any of the developers, and I don't see any
reason to exclude anyone from this.  It's not equivalent to giving
people access to any system, privileges to perform any specific action.
 
It's mostly about confirming which OpenPGP key should be used to send
mail to a particular e-mail address.  The same as if you went to
the developer listing and checked key IDs there, except more automated
and using a single authority key rather than PKI for verification
(though at least initially the authority key would itself be verified
against PKI).

-- 
Best regards,
Michał Górny