Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys

[Michał Górny]

On Sun, 2019-02-24 at 12:04 -0500, Alec Warner wrote:
> On Sun, Feb 24, 2019 at 9:14 AM Michał Górny <mgorny@g.o> wrote:
>
> > ---
> >  glep-9999.rst | 359 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 359 insertions(+)
> >  create mode 100644 glep-9999.rst
> >
> > diff --git a/glep-9999.rst b/glep-9999.rst
> > new file mode 100644
> > index 0000000..d66398b
> > --- /dev/null
> > +++ b/glep-9999.rst
> > @@ -0,0 +1,359 @@
> > +---
> > +GLEP: 9999
> > +Title: Gentoo OpenPGP Authority Keys
> > +Author: Michał Górny <mgorny@g.o>
> > +Type: Standards Track
> > +Status: Draft
> > +Version: 1
> > +Created: 2019-02-24
> > +Last-Modified: 2019-02-24
> > +Post-History:
> > +Content-Type: text/x-rst
> > +Requires: 63
> > +---
> > +
> > +Abstract
> > +========
> > +This GLEP proposes using Authority Keys to provide developer key
> > +validity proofs that are compatible with web of trust.  The signatures
> > +on ``@gentoo.org`` UIDs are automatically maintained, and user can
> > +follow the current set of valid keys by importing and trusting a single
> > +Authority Key.  The system operates within standard features of GnuPG
> > +and requires only minimal setup from the user.
> > +
> > +
> > +Motivation
> > +==========
> > +All the recent efforts on improving OpenPGP usage in Gentoo were focused
> > +on internal usage and distribution.  The existing policies and tooling
> > +are sufficient to account for verify specific usage, including commit
> > +signing (with both internal and user-oriented verification via custom
> > +tools) or release media verification.  However, they do not provide
> > +for rapid OpenPGP deployment for secure communications usage.
> > +
> > +The Gentoo webservers distribute both convenient key bundles
> > +and individual keys via Web Key Directory.  While in both cases
> > +the transfer is secured via HTTPS, providing authenticity verification
> > +via PKI/DNSSEC, those channels are meant to *distribute* the keys
> > +and not provide implicit guarantees on their *validity*.  For example,
> > +they provide no guarantees that the user identifiers on the keys are
> > +legitimate.  [#KEY-BUNDLES]_
> > +
> > +Internally, Gentoo's LDAP directory serves as the canonical source
> > +of information on key validity.  It stores a list of key fingerprints
> > +for each Gentoo developers, and therefore allows the system to establish
> > +which keys are acceptable in context of a specific developer.  However,
> > +the LDAP directory is not available to the public and therefore is only
> > +suitable for internal infrastructure use.  [#LDAP-GUIDE]_
> > +
> > +The Gentoo website is focused on service keys and not individual
> > +developer keys.  While it could easily be amended with full fingerprints
> > +of all developer keys, the necessity of manually verifying such a large
> > +number of keys would be inconvenient to the end user.
> > +[#WWW-SIGNATURES]_
> > +
> > +The key package provided in the Gentoo repository is also focused
> > +on service keys, and has limited value in verifying key validity
> > +(currently, it assumes all UIDs on all keys in the keyring are valid).
> > +Providing a package with developer keys would both require frequent
> > +semi-manual updates, and establishing a more precise validity model.
> > +[#KEY-PACKAGE]_
> > +
> > +Gentoo-keys project provides so-called seed files that carry enough
> > +information to establish key validity, and are authenticated via HTTPS.
> > +However, they rely on installing custom software that does not integrate
> > +well with regular use of GnuPG e.g. in mail clients, and that is not
> > +easily usable in other systems.  [#GENTOO-KEYS]_
> > +
> > +The Authority Key proposal aims to provide a more standard way of
> > +establishing validity of Gentoo developer keys.  It builds upon the web
> > +of trust model, requiring no special software and minimal setup from end
> > +users.
> > +
> > +
> > +Specification
> > +=============
> > +Purpose and usage
> > +-----------------
> > +The purpose of the Authority Keys is to provide an automatically issued
> > +signatures on Gentoo developer OpenPGP keys, based on the information
> > +provided internally in the Gentoo LDAP directory.  The service
> > +is provided for all active Gentoo developers, from the moment of their
> > +recruitment.
> > +
> > +Whenever a developer account is created, reactivated, renamed or has
> > +a new key fingerprint added, a signature is automatically created
> > +on the appropriate ``@gentoo.org`` UIDs and pushed to the keyservers.
> > +Whenever an old signature expires, a new one is automatically created.
> > +Whenever a developer account is disabled, renamed or has a fingerprint
> > +removed, the signatures from obsolete UIDs are automatically revoked.
> > +
> > +The signatures are issued only on the UIDs matching the Gentoo
> > +developer's ``@gentoo.org`` mailbox address, on keys whose primary key
> > +fingerprints are listed in Gentoo LDAP ``gpgfingerprint`` records.  Keys
> > +missing such an UID are ignored.  **Names on the relevant user
> > +identifiers are not verified**.  The signatures are issued with
> > +an expiration date of 1 year from being issued.
> > +
> > +
> > +L1 and L2 keys
> > +--------------
> > +The Authority Keys are issued in two layers, appropriately called L1
> > +and L2.
> > +
> > +The single L1 Authority Key is used only to (manually) certify the L2
> > +Keys, and is kept securely offline following the Infrastructure policies
> > +on protecting primary keys.  The fingerprint of this key is published
> > +on the Gentoo website and users are requested to sign this key to enable
> > +key validity via Authority Keys.
> >
>
> +
> > +The L2 Authority Keys are used directly to sign developer keys.  Since
> > +they are used in an automated service, they are exposed to attacks.
> > +They are trust-signed by the L1 key and can be revoked and rotated more
> > +frequently than the L1 key.
> > +
> > +This dual-layer model aims to combine improved security with user
> > +convenience.  While the individual Gentoo keys are signed by the L2 key,
> > +the users sign only the L1 key and the validity is established via chain
> > +L1 → L2 → developer key.  This makes it possible to replace the L2 key
> > +if it ever becomes compromised without requiring the users to
> > +reestablish trust.  Since the replacement key will be also signed
> > +by the L1 key (provided that it was not compromised), the validity
> > +of developer keys will remain established.
> > +
> > +
> > +Validating the L1 key
> > +---------------------
> > +Establishing the authenticity of the L1 Authority Key is essential
> > +to the system.  Initially, the users will be able to determine
> > +the authenticity via comparing the key fingerprint with the one
> > +published on the website.  This will shift the authenticity verification
> > +to HTTPS (PKI/DNSSEC).
> > +
> > +However, at the same time users are encouraged to sign the key upon
> > +verifying it.  This will effectively make it possible to establish key's
> > +validity via OpenPGP web of trust.
> >
>
> Is the L1 specific to signing packages, or does it have other duties?

"The single L1 Authority Key is used only to (manually) certify the L2
Keys".  No more duties.

>
>
> > +
> > +
> > +Rationale
> > +=========
> > +Authority Key model vs web of trust
> > +-----------------------------------
> > +The regular web of trust model relies on individuals verifying
> > +the Gentoo developer identity and access to the particular
> > +``@gentoo.org`` e-mail address.  The particular UID is considered valid
> > +if a sufficient number of people trusted by the user in question have
> > +confirmed the developer's identity.  This specifically relies on being
> > +able to establish a chain of trust between the developer and user.
> > +
> > +At the moment, many of the existing Gentoo developers did not even
> > +stablish a chain of trust between one another, not to mention establish
> >
>
> establish

Fixed.

> +web of trust coverage that would make it feasible for users to reach any
> > +specific developer.  Efforts towards improving that were rejected
> > +by the developers, mostly based on argumentation that many developers
> > +find it impossible to meet any other community member for the purpose
> > +of identity verification.
> > +
> > +The Authority Key model, on the other hand, assumes that there is
> > +a single trusted authority that verifies Gentoo developers' keys.
> > +The user verifies the key representing this authority and trusts it.
> > +The validity of keys used by all developers is established via a single
> > +point of trust.
> > +
> > +The procedure of establishing the validity of a specific key does not
> > +involve the necessity of meeting anyone or verifying identity.  While
> > +the validity is exposed in a manner compatible with web of trust, it is
> > +verified against LDAP which implicitly proves authenticity of the keys.
> > +
> > +Therefore, the Authority Key model is much easier to set up.  The user
> > +merely needs to verify a single key and trust it, while pure WoT would
> > +probably require trusting multiple third party identities.  It is also
> > +more secure as it limits the attack vector to a single key rather than
> > +one of potentially large number of keys that need to be trusted by
> > +the user.  If the user decides to stop trusting ``@gentoo.org`` UIDs,
> > +the validity can easily be reverted by disabling the single Authority
> > +Key.
> >
>
> Yeah I like the revocation a lot better in this proposal, the previous one
> seemed a bit impractical.

Revocation is the same as in the original.  Maybe worded more verbosely?

-- 
Best regards,
Michał Górny