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

[Robin H. Johnson]

On Mon, Feb 18, 2019 at 02:22:56PM +0100, Michał Górny wrote:
> > 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:
Thanks for expounding on the list of issues. I think this covers
all/most of the cases I had in my head.

> 1) someone manages to compromise LDAP without compromising e-mail
> service,
- Compromising email has a couple of routes: 
  1. Getting into dev.gentoo.org (SSH creds). 
     Either lets you see mail directly there, or edit the forward. 
  OR
  2. If a dev has their mail forwarded, you can also compromise
     somewhere else in the forwarding chain.
- Compromising LDAP requires:
  1. A shell in a larger set of machines (need SSH creds to any user on hosts that are LDAP clients)
  AND 
  2. A LDAP password with suitable power (note that the SSH creds and
  LDAP password could be from different compromised users), which means
  either the target, or the LDAP password of somebody in
  comrel/recruiters/infra.

> 2) a developer accidentally puts the wrong fingerprint in LDAP,
This has happened before; esp w/ devs putting subkeys into LDAP. If not
in-band with this proposal (e.g. CAFF), can we see some other validation
for the keys?

> 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.

3) would be good to detect on the less-active devs, and gives good
life-signs to undertakers.

> 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.
Save the signature to a file, email the file, retain the file for
record-keeping, resend the file until they do something about it. I
think the CAFF codebase does already support this variant to not
regenerate pending signatures.

> 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.
Users sending mail to an unverified key seems like a concern to me.

> 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).
Related codepath not discussed yet:
- detect keys REMOVED from ldap and generate revoke of signature on those.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@g.o
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136