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

[Alec Warner <antarus@gentoo.org>]

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

On Sun, Feb 24, 2019 at 12:10 PM Michał Górny <mgorny@gentoo.org> wrote:

> 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@gentoo.org> 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@gentoo.org>
> > > +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?
>

Oh sorry, the previous proposal being the original wot one (where
revocation meant "everyone has to revoke the signature of any developer who
leaves")

-A


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

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