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

[Michał Górny]

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