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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

Hi,

Following the replies to my earlier GLEP, I'd like to separately discuss
introducing Authority Keys to provide validity proof for @gentoo.org
UIDs.

TL;DR: we'd create OpenPGP key that will be used to (semi-?)
automatically sign @gentoo.org UIDs on developer keys (as listed
in LDAP), so users could trust this key and have all developers verified
instantly.


Problem being solved: making it possible for users to easily verify
developer keys and distinguish them from potential fraud.  Since
by definition Gentoo developers are people having access to Gentoo
servers, it is reasonable to use the key fingerprints stored there
as point of truth.

This is somewhat already achieved by gentoo-keys seeds file.  However,
that file is entirely custom and it doesn't work out of the box outside
gkeys environment.  On the other hand, WoT-based validity checks are
built-in in GnuPG and can be semi-reasonably used for this purpose.

The generic idea is that we'd publish an 'Authority Key' with its
fingerprint presented on the website along with service keys.  We'd sign
all @gentoo.org UIDs matching LDAP entries with this key and publish
the signatures on keyservers.  Then the user would fetch this authority
key, verify its fingerprint, set it to full trust and WoT calculation
would automatically result in all developer keys being trusted.

Developer key revocation: having a single signing point also makes it
easy to handle revocations (e.g. due to developers retiring).  We would
just have to revoke the relevant signatures, and publish updates.


Authority Key protection: since keysigning is done using the primary
key, it would have to be exposed to attacks.  Unlike with subkeys, we
would have to revoke the whole key in case of compromise.

Therefore, I would like to propose creating two layers of Authority
Keys: L1 and L2.  The L1 key would be protected strongly and used only
to sign L2 key.  The L2 key would be used to sign actual keys.

Users would only validate L1 key, and L2 would become valid implicitly. 
If L2 ever becomes compromised, we'd revoke it and use L1 to sign a new
key.  This way, GnuPG would appropriately stop trusting old L2
and verify new L2 as valid.


Your comments?  Anything I've missed?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 864 bytes --]

On 2/16/19 9:40 AM, Michał Górny wrote:
> Therefore, I would like to propose creating two layers of Authority
> Keys: L1 and L2.  The L1 key would be protected strongly and used only
> to sign L2 key.  The L2 key would be used to sign actual keys.
> 
> Users would only validate L1 key, and L2 would become valid implicitly. 
> If L2 ever becomes compromised, we'd revoke it and use L1 to sign a new
> key.  This way, GnuPG would appropriately stop trusting old L2
> and verify new L2 as valid.
> 
> 
> Your comments?  Anything I've missed?
This is a good idea IMO
(FWIW I think the Tor people hanlde in a similar manner the relay keys. The "L1" should be kept off-line dieally - or at least have a strong password - whilst L2 is signed by L1 valid for few weeks/months, depending on the choice of the user)

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

Am Samstag, 16. Februar 2019, 09:40:21 CET schrieb Michał Górny:
> 
> Your comments?  Anything I've missed?

Excellent plan, let's do it!

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Aaron Bauman]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Sat, Feb 16, 2019 at 09:40:21AM +0100, Michał Górny wrote:
> Hi,
> 
> Following the replies to my earlier GLEP, I'd like to separately discuss
> introducing Authority Keys to provide validity proof for @gentoo.org
> UIDs.
> 

I believe you will find resistance from the usual crowd who are
advocating for key signing with validation of some form of
identification. However, I would offer that this identification
requirement does not help determine or predict intent.

Aside from that, I like the proposal and find it "meets in the middle"
of any other approaches out there.  As it stands, users trust Gentoo as
a distribution and will most likely extend that trust with this process
in place.

Regarding the overall intent of keys and key signing, the goal would be
to inherently trust someone of which no ID is going to assist anyone in.
It is a perpetual process like any normal relationship and can be
altered at anytime.

This falls back on Gentoo to ensure we can trust those developers in
some form.  I would offer that a potential "probationary" period be
established before that individuals key is signed by the distribution
and distributed.  Possibly, it is a part of the recruitment process or
may need to be extended further.  Ultimately, the recruiters and mentors
hold the line for the protection of the distribution when on-boarding new
developers.

I like it... let's do it!

-- 
Cheers,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]

On Sat, Feb 16, 2019 at 09:40:21AM +0100, Michał Górny wrote:
> Your comments?  Anything I've missed?
Overall, strong +1 to the idea.

Some questions/remarks:
0. I will oppose any intentions to tie this proposal to the GLEP76 or other
requirements of disclosing "legal" names. I realize other developers may object
to this, but I don't believe that "legal" names in this context actually gain
us anything of value. 

1. Where are non-dev users trying to verify developer keys directly at the
moment? I thought all prior work discouraged that, in favour of verifying
service keys instead. I do see this proposal being of a LOT more use in the
infra-run systems that verify incoming commits/pushes.

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.

3. As raised elsewhere on the thread, what delays should be implicit on a new
dev joining vs having their key auto-signed?

4. uid signatures cannot generally exceed the lifetime of a primary key; the L2
signing service will need to resign regularly. How will this interact with the
CAFF design above?

5. You state that the users should trust the L1 key directly. Can you clarify
your intent here to cover the trust?

The most obvious interpretation to me is trust signature of of the L2 key, with
depth=2 domain=gentoo.org [1].

[1] trust signatures domain restrictions are actually regular
expressions; but GnuPG limits the input thereof. Just answering the
query:
> Please enter a domain to restrict this signature, or enter for none.
> Your selection? gentoo.org
Actually generates:
> :signature packet: algo 22, keyid THROWAWAY
>	version 4, created 1550385418, md5len 0, sigclass 0x10
>	digest algo 8, begin of digest f0 e4
>	hashed subpkt 33 len 21 (issuer fpr v4 THROWAWAY)
>	hashed subpkt 2 len 4 (sig created 2019-02-17)
>	hashed subpkt 5 len 2 (trust signature of depth 2, value 120)
>	critical hashed subpkt 6 len 24 (regular expression: "<[^>]+[@.]gentoo\x5c.org>$\0")
>	subpkt 16 len 8 (issuer key ID THROWAWAY)
>	data: [255 bits]
>	data: [256 bits]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3173 bytes --]

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:
> > Your comments?  Anything I've missed?
> 
> Overall, strong +1 to the idea.
> 
> Some questions/remarks:
> 0. I will oppose any intentions to tie this proposal to the GLEP76 or other
> requirements of disclosing "legal" names. I realize other developers may object
> to this, but I don't believe that "legal" names in this context actually gain
> us anything of value. 

That's outside the scope.  The key will be explicitly described
as verifying the @gentoo.org account ownership only.

> 1. Where are non-dev users trying to verify developer keys directly at the
> moment? I thought all prior work discouraged that, in favour of verifying
> service keys instead. I do see this proposal being of a LOT more use in the
> infra-run systems that verify incoming commits/pushes.

My main purpose is mail.

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

> 3. As raised elsewhere on the thread, what delays should be implicit on a new
> dev joining vs having their key auto-signed?

I don't see any need for delay.  As soon as the user can access LDAP
and add his key, he's proven that he owns the @gentoo.org address
at the moment.

> 4. uid signatures cannot generally exceed the lifetime of a primary key; the L2
> signing service will need to resign regularly. How will this interact with the
> CAFF design above?

Adds to the 'can of worms'.

> 5. You state that the users should trust the L1 key directly. Can you clarify
> your intent here to cover the trust?
> 
> The most obvious interpretation to me is trust signature of of the L2 key, with
> depth=2 domain=gentoo.org [1].

Yes, something along the lines of that.

> 
> [1] trust signatures domain restrictions are actually regular
> expressions; but GnuPG limits the input thereof. Just answering the
> query:
> > Please enter a domain to restrict this signature, or enter for none.
> > Your selection? gentoo.org
> 
> Actually generates:
> > :signature packet: algo 22, keyid THROWAWAY
> > 	version 4, created 1550385418, md5len 0, sigclass 0x10
> > 	digest algo 8, begin of digest f0 e4
> > 	hashed subpkt 33 len 21 (issuer fpr v4 THROWAWAY)
> > 	hashed subpkt 2 len 4 (sig created 2019-02-17)
> > 	hashed subpkt 5 len 2 (trust signature of depth 2, value 120)
> > 	critical hashed subpkt 6 len 24 (regular expression: "<[^>]+[@.]gentoo\x5c.org>$\0")
> > 	subpkt 16 len 8 (issuer key ID THROWAWAY)
> > 	data: [255 bits]
> > 	data: [256 bits]
> 
> 

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

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

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1453 bytes --]

On 2/17/19 7:54 PM, 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).

Different threat models, if you assume the malicious actor can edit the
fingerprint in LDAP to begin with they have access to the email itself,
and we control the email address since only the @gentoo.org UID is signed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3503 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 4418 bytes --]

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@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5970 bytes --]

On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote:
> 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. 

Also note that this would also happen if one of infra members'
credentials + sudo password leaked.

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

I think the simplest verification would be to verify that
the corresponding key has appropriate @gentoo.org UID.  If it doesn't,
there will be no UID to sign anyway, so it wouldn't harm the process.

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

Maybe.  However, we're practically talking about one-time check here. 
Once the key is initially signed (and if the developer ignores GLEP 63
expiration suggestions), there will be no reason to mail him again.

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

Gentoo developer would argue that a key is unverified if they make
commits with it.  Maybe we could use that as some kind of implicit
metric.

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

Actually, I had thought of that and the demo implementation [1] supports
that already.  Basically, it compares list of fpr+uid from LDAP with
UIDs trusted on locally known keys (provided that new keys and updates
are fetched but old keys aren't removed).  If new fpr+uid is added to
LDAP, the diff causes it to be signed.  If fpr+uid disappears from LDAP,
the diff causes signature to be revoked.

This has a corner case/bug that if we revoke a signature, gpg normally
doesn't let us sign the same uid again.  However, this is rather rare
(would happen either for returning devs or because of script bugs)
and we can circumvent it manually by removing the old signature (then
gpg lets us sign again, and the new signature works fine afterwards).

[1]:https://github.com/mgorny/gentoo-authority-key

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Rich Freeman]

On Tue, Feb 19, 2019 at 3:01 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote:
> >
> > 3) would be good to detect on the less-active devs, and gives good
> > life-signs to undertakers.
>
> Maybe.  However, we're practically talking about one-time check here.
> Once the key is initially signed (and if the developer ignores GLEP 63
> expiration suggestions), there will be no reason to mail him again.

Until now this has seemed like something that didn't require any
manual developer participation.

Now it is sounding like a proposal that both requires manual
participation, and may also require manual updating, to avoid
undertaking.

It seems like it would make far more sense to look at other direct
measures of activity than how up-to-date their gpg key is in the
keyservers.

Also, as far as I'm aware GLEP 63 does not require an encryption key
at all, just a signing key.  I'm not sure if such signing-keys will be
signed by Gentoo under this proposal.  If not then there is nothing to
upload to the keyserver, and in any case it seems like the main use
case of this (sending encrypted email) would not apply.  Of course it
could still be used for verifying email signatures if we sign
signing-only keys.

-- 
Rich

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]

On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman <rich0@gentoo.org> wrote:

> On Tue, Feb 19, 2019 at 3:01 PM Michał Górny <mgorny@gentoo.org> wrote:
> >
> > On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote:
> > >
> > > 3) would be good to detect on the less-active devs, and gives good
> > > life-signs to undertakers.
> >
> > Maybe.  However, we're practically talking about one-time check here.
> > Once the key is initially signed (and if the developer ignores GLEP 63
> > expiration suggestions), there will be no reason to mail him again.
>
> Until now this has seemed like something that didn't require any
> manual developer participation.
>

> Now it is sounding like a proposal that both requires manual
> participation, and may also require manual updating, to avoid
> undertaking.


The authority scheme is *already* in use today. We currently allow any FP
in LDAP  with an @gentoo.org address to commit. This proposal just
standardizes it using existing tooling so that users can consume the trust
graph easily. The base proposal doesn't change any of the rules, just the
implementation; to make it *easier* for end users to use the authority
scheme. This is a net good for Gentoo, IMHO, as we should use and adopt
standards of the time. Our current authority scheme doesn't use CAFF and
does not verify gpg fingerprints in LDAP.

CAFF addresses a deficiency in the current system. Currently we don't
validate control over fingerprints in LDAP. This means once an attacker
gains LDAP access, they only need to add a key fingerprint to an LDAP
record in order to get their commits through the GPG verification process.

With CAFF, the attacker has more work to do because CAFF will make the
attacker show ownership of the private portion of the keypair before we
grant it authority. This has some benefit as it makes it more likely for
the attacker to make a mistake and get caught, or leave a trail for us to
find. If they fail CAFF (e.g. use the wrong key) or commit without a CAFF
key, we can use those as signals to detect tampering and intrusion.

I consider CAFF to be important (as something we should do) but not a
requirement (something we must do in order) in this implementation of the
authority scheme.


>
> It seems like it would make far more sense to look at other direct
> measures of activity than how up-to-date their gpg key is in the
> keyservers.
>

I'm bad at GPG. However, I believe updating my keys to adapt to the policy
took me about 30 minutes. Its required once every 12 months.

Where should we set the bar here, if not "please contribute at least 30
minutes every year to retain your developership."


> Also, as far as I'm aware GLEP 63 does not require an encryption key
> at all, just a signing key.  I'm not sure if such signing-keys will be
> signed by Gentoo under this proposal.  If not then there is nothing to
> upload to the keyserver, and in any case it seems like the main use
> case of this (sending encrypted email) would not apply.  Of course it
> could still be used for verifying email signatures if we sign
> signing-only keys.
>

This does seem like a gap.

-A


>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 4509 bytes --]

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

[Rich Freeman]

On Tue, Feb 19, 2019 at 4:54 PM Alec Warner <antarus@gentoo.org> wrote:
> On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman <rich0@gentoo.org> wrote:
>>
>> Now it is sounding like a proposal that both requires manual
>> participation, and may also require manual updating, to avoid
>> undertaking.
>
>
> The authority scheme is *already* in use today.

I'm referring to the need to do CAFF, not the need to have a gpg key in LDAP.

> With CAFF, the attacker has more work to do because CAFF will make
> the attacker show ownership of the private portion of the keypair
> before we grant it authority. This has some benefit as it makes it
> more likely for the attacker to make a mistake and get caught, or
> leave a trail for us to find. If they fail CAFF (e.g. use the wrong
> key) or commit without a CAFF key, we can use those as signals to
> detect tampering and intrusion.

Why would an attacker replace a key in LDAP with one they don't control?

If they control LDAP, then they control the @gentoo.org email address
already, should they exercise this control.  That means they can
redirect the email, change the key, obtain their signature, and upload
their signature.  That is more steps, but not more security.

>> It seems like it would make far more sense to look at other direct
>> measures of activity than how up-to-date their gpg key is in the
>> keyservers.
>
> I'm bad at GPG. However, I believe updating my keys to adapt to the policy took me about 30 minutes. Its required once every 12 months.

Updating your keys is a one-liner with a shell script.  It doesn't not
require messing with emails.  Sure, shell-scripting email isn't
impossible, but I don't see what value it adds.

You can already test whether devs are updating their gpg keys or not
without messing with CAFF.

>
> Where should we set the bar here, if not "please contribute at least 30 minutes every year to retain your developership."

How about doing ACTUAL activity?  Not make-work?

If somebody is actually doing commits in the tree, you know they're
active and don't need them to jump through some additional hoops.

And of course there are other types of activity where git signing keys
aren't needed, and thus those hoops don't even add value in the first
place, and where that other activity could be measured (number of
forum logins/posts/whatevers, and so on).

>
>>
>> Also, as far as I'm aware GLEP 63 does not require an encryption key
>> at all, just a signing key.  I'm not sure if such signing-keys will be
>> signed by Gentoo under this proposal.  If not then there is nothing to
>> upload to the keyserver, and in any case it seems like the main use
>> case of this (sending encrypted email) would not apply.  Of course it
>> could still be used for verifying email signatures if we sign
>> signing-only keys.
>
> This does seem like a gap.
>

Only if you make it into one.  If some dev has zero interest in
receiving gpg-encrypted mail, encouraging people to gpg-encrypt mail
to them just means that their mail goes to /dev/null, especially if
they have their mail clients configured to auto-encrypt stuff.

I mean, if I'm in infra and somebody needs to mail me the root keys to
some box I can see the point in it, but 99% of what would get
encrypted is stuff that could probably get by just being clear signed.

-- 
Rich

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On Tue, 2019-02-19 at 16:54 -0500, Alec Warner wrote:
> > It seems like it would make far more sense to look at other direct
> > measures of activity than how up-to-date their gpg key is in the
> > keyservers.
> > 
> 
> I'm bad at GPG. However, I believe updating my keys to adapt to the policy
> took me about 30 minutes. Its required once every 12 months.
> 
> Where should we set the bar here, if not "please contribute at least 30
> minutes every year to retain your developership."
> 

There are a few problems here.

Firstly, we have a fair share of developers who don't follow any news,
and just do little Gentoo in their little corner.  You need to find
a way to communicate this new requirement to them.  They will be
probably outraged they have to do yet another thing to stay developers.

Secondly, retiring developers is a nasty business.  Imagine people who
haven't done anything in N years, ignore retirement mail and then insult
us that we didn't go out of our way to discover they've lost access to
their Gentoo account years ago and never bothered to ask for reinstating
it.  Now imagine what we're going to get for dare trying to retire
someone who ignored a few CAFF mails.  Or retiring the same person after
it ignored all the retirement mail.

Thirdly, as I said, it introduces operation gaps.  My original goal is
to make it possible for users to mail devs anytime.  It's not going to
be nice to have gaps of one week between old signature expiring
and developer getting around to publish a new one.  Not to mention
the obvious failure of importing the signature and forgetting to send it
to keyservers.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Tue, 2019-02-19 at 15:16 -0500, Rich Freeman wrote:
> Also, as far as I'm aware GLEP 63 does not require an encryption key
> at all, just a signing key.  I'm not sure if such signing-keys will be
> signed by Gentoo under this proposal.  If not then there is nothing to
> upload to the keyserver, and in any case it seems like the main use
> case of this (sending encrypted email) would not apply.  Of course it
> could still be used for verifying email signatures if we sign
> signing-only keys.

If someone really believes it's fine to have no encryption subkey just
because the GLEP doesn't require one explicitly...  It either means that
person is seriously lacking the technical competence, or is a horrible
troll.  In either case, I don't believe such a person should be a Gentoo
developer.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Rich Freeman]

On Sat, Feb 23, 2019 at 2:46 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Tue, 2019-02-19 at 15:16 -0500, Rich Freeman wrote:
> > Also, as far as I'm aware GLEP 63 does not require an encryption key
> > at all, just a signing key.  I'm not sure if such signing-keys will be
> > signed by Gentoo under this proposal.  If not then there is nothing to
> > upload to the keyserver, and in any case it seems like the main use
> > case of this (sending encrypted email) would not apply.  Of course it
> > could still be used for verifying email signatures if we sign
> > signing-only keys.
>
> If someone really believes it's fine to have no encryption subkey just
> because the GLEP doesn't require one explicitly...  It either means that
> person is seriously lacking the technical competence, or is a horrible
> troll.  In either case, I don't believe such a person should be a Gentoo
> developer.

The reason we write policies down is so that we can follow them.

I have a signing-only key, which I think was created following some
published procedure at the time.  I see a newer wiki article on the
subject that talks about creating a Gentoo key and it mentions that
creating an encryption subkey is recommended, though it does not say
it is required (which is correct).

In any case, if we want everybody to have an encryption subkey, then
just make it part of the GLEP.  No trolling is intended, at least for
my part.

My Gentoo commit signing key is not used for anything else.  I
generate it to follow the requirements of the GLEP, and it is designed
to be throw-away so that if the GLEP changes I can just roll up a new
key anytime.  I have no need to receive encrypted email using this
key, so it isn't set up.  Decrypting mail sent to me would be a pain
since I don't use a gpg-aware MUA, so I really don't want to do
anything to encourage people to send me encrypted mail.  However, I
think I have my Gentoo email address on my regular gpg key that is
part of the strong set and it allows encryption.  It isn't in LDAP so
it wouldn't be signed using the proposed scheme.

BTW, I'll also note that the guidelines for creating keys requires
modification to gpg config vs just using command line options.  That
seems like a rather painful way of making Gentoo-specific keys.  I
think I ended up just setting up a container for Gentoo key generation
so that I could just meet whatever specific requirements are set out
and not interfere with the real world.  Maybe one of these days I'll
get around to shell-scripting the entire process so that instead of
extending key expiry I can just revoke my old key, generate a new key,
put it in LDAP, add it to my regular keyring, and update make.conf.
On a side note I will note that gpg is a bit annoying in its
interactivity when it comes to key manipulation.

-- 
Rich

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

On Sat, Feb 23, 2019 at 2:46 AM Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 2019-02-19 at 15:16 -0500, Rich Freeman wrote:
> > Also, as far as I'm aware GLEP 63 does not require an encryption key
> > at all, just a signing key.  I'm not sure if such signing-keys will be
> > signed by Gentoo under this proposal.  If not then there is nothing to
> > upload to the keyserver, and in any case it seems like the main use
> > case of this (sending encrypted email) would not apply.  Of course it
> > could still be used for verifying email signatures if we sign
> > signing-only keys.
>
> If someone really believes it's fine to have no encryption subkey just
> because the GLEP doesn't require one explicitly...  It either means that
> person is seriously lacking the technical competence, or is a horrible
> troll.  In either case, I don't believe such a person should be a Gentoo
> developer.
>

- Why does setting up GPG to receive encrypted messages imply technical
competence?

- As rich noted, most people have no idea how GPG works and they just do
whatever they are instructed to do. I don't think a lack of knowledge of
GPG indicates "being a troll" nor "lack of technical competence." Its a
terribly designed piece of software from a usability perspective. I
understand its a complex space (as many security domains are) but I'm not
sure the right way to proceed is to force everyone to learn the inner
workings of the space. The goal should be to create a system where users
don't have to know all the details but still get a good security value.

-A


>
> --
> Best regards,
> Michał Górny
>

[-- Attachment #2: Type: text/html, Size: 2268 bytes --]

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

[Rich Freeman]

On Sat, Feb 23, 2019 at 11:30 AM Alec Warner <antarus@gentoo.org> wrote:
>
> - As rich noted, most people have no idea how GPG works and they
> just do whatever they are instructed to do. I don't think a lack of
> knowledge of GPG indicates "being a troll" nor "lack of technical
> competence."

I wasn't even arguing ignorance.  I've been using PGP since the days
when I had to jump through hoops to get around the ITAR restrictions.

I don't follow the Gentoo instructions because I don't know how to use
gpg.  I follow them because the GLEP has a stack of requirements for
how a Gentoo gpg key ought to be set up, and since I have no intention
of ever using the key for anything else, there is no reason to waste
time tailoring it to my own needs.  It is no different from my company
laptop - I configure it however they want me to and don't use it for
anything personal.  That isn't because I don't know how to use gmail
or Facebook or whatever on it, but simply because it makes no sense
for me to get frustrated with whatever the IT policy is of the day
when a laptop starts at $120 these days and I can just use my own, and
I have independent internet anywhere I go.

Likewise the reason I don't sign my email isn't because I don't know
how thunderbird/kmail/whatever works.  It is because there isn't much
intersection between MUAs that fit how I actually access email these
days and MUAs that can securely access my key.  If my Gentoo email
workflow required a more gpg-centric workflow then I'd set up a
separate email account just for Gentoo, use Thunderbird or whatever
with it on a single desktop, and not look at it much except when I had
to.  Or maybe if it were supported I'd use a different key for email
so that I wouldn't need to go sticking my commit-signing key on every
phone/laptop/whatever I use where it could get compromised and end up
with some poor soul getting rooted, and I could be more liberal with
the email key.  Really though I suspect that some of the newer
x509-based protocols are better-supported by email clients.

I've been involved with Gentoo in one way or another for approaching
15 years and in all that time I think I've had to use gpg for
something other than commit-signing maybe once or twice.  Nothing
wrong with using it, and I accept that some roles might require it
more often, but it seems a bit overkill to invest a ton of time in
secure email for an organization that almost never needs secure email.

No trolling intended.  I just don't see the point.  If it were
required then I would comply.  I completely get the spirit vs the
letter of the rules, but IMO this doesn't fall under either.  As far
as I can tell there was never any intent to require an email signing
subkey, and this was not a mere accidental omission, at least not on
the part of the majority of council members who voted for the policy.

-- 
Rich

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Sat, 2019-02-23 at 11:30 -0500, Alec Warner wrote:
> On Sat, Feb 23, 2019 at 2:46 AM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Tue, 2019-02-19 at 15:16 -0500, Rich Freeman wrote:
> > > Also, as far as I'm aware GLEP 63 does not require an encryption key
> > > at all, just a signing key.  I'm not sure if such signing-keys will be
> > > signed by Gentoo under this proposal.  If not then there is nothing to
> > > upload to the keyserver, and in any case it seems like the main use
> > > case of this (sending encrypted email) would not apply.  Of course it
> > > could still be used for verifying email signatures if we sign
> > > signing-only keys.
> > 
> > If someone really believes it's fine to have no encryption subkey just
> > because the GLEP doesn't require one explicitly...  It either means that
> > person is seriously lacking the technical competence, or is a horrible
> > troll.  In either case, I don't believe such a person should be a Gentoo
> > developer.
> > 
> 
> - Why does setting up GPG to receive encrypted messages imply technical
> competence?

The default GnuPG setup involves supporting encryption.  In order not to
support encryption, you have to actually go out of your way to create
signing-only setup which makes no sense.

> - As rich noted, most people have no idea how GPG works and they just do
> whatever they are instructed to do. I don't think a lack of knowledge of
> GPG indicates "being a troll" nor "lack of technical competence." Its a
> terribly designed piece of software from a usability perspective. I
> understand its a complex space (as many security domains are) but I'm not
> sure the right way to proceed is to force everyone to learn the inner
> workings of the space. The goal should be to create a system where users
> don't have to know all the details but still get a good security value.
> 

The question is: how can you actually guarantee that users that don't
understand OpenPGP/GnuPG basics can actually comprehend the basic
necessities of keeping their key secure?  Next thing I learn is that
people are not protecting their keys with password because
the instructions didn't say they had to.  And GnuPG *only warned*.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Rich Freeman]

On Sat, Feb 23, 2019 at 12:08 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> The question is: how can you actually guarantee that users that don't
> understand OpenPGP/GnuPG basics can actually comprehend the basic
> necessities of keeping their key secure?

I think you need to distinguish between people who don't understand
gpg and people who simply don't agree with you.  As you pointed out,
in its default config gpg generates an encryption subkey.  Though, I
don't think the default config is actually Gentoo-compatible.

> Next thing I learn is that
> people are not protecting their keys with password because
> the instructions didn't say they had to.  And GnuPG *only warned*.

While it is always a good idea to protect a key with a password, this
really only protects the key while it is at rest.  Chances are if an
attacker can read the keyring from disk, they can probably also
intercept the passphrase, either from the keyboard or from the gpg or
agent process.

If we really want to protect keys then it probably makes sense to
generate them on hardware keys, and use a hardware key which makes it
possible to distinguish keys that were generated on-hardware and are
non-exportable from keys that were generated in software (probably by
use of a remote attestation signing key in the hardware).  I'm not
sure if such hardware keys exist.  I guess another option is to have a
trusted person generate the keys on-hardware, load the key ID into
LDAP, and not let devs change their LDAP settings.  Of course that
would give the person generating keys the ability to secretly generate
some, keep a copy of the private key, and then load it on the
hardware.  Then again, with any hardware device you're also trusting
the manufacturer to not have a backdoor either.

Bottom line is that PKI is hard.  You can encourage devs to follow
better practices, just as you can encourage them to run repoman, but
in the end they're going to have to be convinced that they really are
the weakest link, otherwise they'll probably quietly ignore you.

-- 
Rich

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 290 bytes --]

On 2/16/19 9:40 AM, Michał Górny wrote:
> Your comments?  Anything I've missed?

As discussed previously I believe this is a good idea.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Eray Aslan]

On Sat, Feb 16, 2019 at 09:40:21AM +0100, Michał Górny wrote:
> Therefore, I would like to propose creating two layers of Authority
> Keys: L1 and L2.  The L1 key would be protected strongly and used only
> to sign L2 key.  The L2 key would be used to sign actual keys.

Good idea.  DNSSEC uses a similar method with KSK (key signing keys) and
ZSK (zone signing keys).

> Your comments?  Anything I've missed?

Problems usually arise when doing key rollovers.  Good automation and
lots of testing would be prudent before going live.

-- 
Eray