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