From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AD3EB138334 for ; Sun, 24 Feb 2019 17:10:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B28DBE08CA; Sun, 24 Feb 2019 17:10:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6E2DCE08B1 for ; Sun, 24 Feb 2019 17:10:48 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6062233D5A5; Sun, 24 Feb 2019 17:10:46 +0000 (UTC) Message-ID: <1551028237.21411.4.camel@gentoo.org> Subject: Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Sun, 24 Feb 2019 18:10:37 +0100 In-Reply-To: References: <20190224141356.7707-1-mgorny@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-ot/ubNc/ufjn98q6vLwY" X-Mailer: Evolution 3.26.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 X-Archives-Salt: a011f2d0-7da9-4033-9d9a-d6b549b7035d X-Archives-Hash: 57e94316651848e0b2ab2f2c6d4178ca --=-ot/ubNc/ufjn98q6vLwY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2019-02-24 at 12:04 -0500, Alec Warner wrote: > On Sun, Feb 24, 2019 at 9:14 AM Micha=C5=82 G=C3=B3rny wrote: >=20 > > --- > > glep-9999.rst | 359 ++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 359 insertions(+) > > create mode 100644 glep-9999.rst > >=20 > > 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=C5=82 G=C3=B3rny > > +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 > > +=3D=3D=3D=3D=3D=3D=3D=3D > > +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 singl= e > > +Authority Key. The system operates within standard features of GnuPG > > +and requires only minimal setup from the user. > > + > > + > > +Motivation > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +All the recent efforts on improving OpenPGP usage in Gentoo were focus= ed > > +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 establi= sh > > +which keys are acceptable in context of a specific developer. However= , > > +the LDAP directory is not available to the public and therefore is onl= y > > +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 fingerprin= ts > > +of all developer keys, the necessity of manually verifying such a larg= e > > +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 integra= te > > +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 we= b > > +of trust model, requiring no special software and minimal setup from e= nd > > +users. > > + > > + > > +Specification > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +Purpose and usage > > +----------------- > > +The purpose of the Authority Keys is to provide an automatically issue= d > > +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. Ke= ys > > +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 polici= es > > +on protecting primary keys. The fingerprint of this key is published > > +on the Gentoo website and users are requested to sign this key to enab= le > > +key validity via Authority Keys. > >=20 >=20 > + > > +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 mor= e > > +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 ke= y, > > +the users sign only the L1 key and the validity is established via cha= in > > +L1 =E2=86=92 L2 =E2=86=92 developer key. This makes it possible to re= place 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 verificati= on > > +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. > >=20 >=20 > 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. >=20 >=20 > > + > > + > > +Rationale > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +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 vali= d > > +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 establis= h > >=20 >=20 > 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 singl= e > > +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 i= s > > +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. > >=20 >=20 > Yeah I like the revocation a lot better in this proposal, the previous on= e > seemed a bit impractical. Revocation is the same as in the original. Maybe worded more verbosely? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-ot/ubNc/ufjn98q6vLwY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlxy0A1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQoWJA/9GYYLBrkosG9Jv/dqEzJ0wRpLz4jm/RX9od4NvocXe5ZjI2q9k+uBZee3 FMEh80aQ92fuO/CIyrlT89VBqM/JAJ7TiYsBpLvl3IkZORJNUcT3DBl+XBPyuyGb 6/udC/u1yIa2IMvGCsWxCjMgO8GiSLwYIpVEA3P0y5WbgF+e5FIYkaocVMlfLXnd K6uGmrMj6KaSaZkZRMuHxiDYxlv4SBSBavB9wGRpH9+/6bGNgkxbaZC6+EVAipaO 9DAXEUprnd//7bFL1EJdFPiccF7Psz1HHvE5LyyOTgVNIZ2aozW6yrWryr1qFAb9 5QrMJfbG1ssSBy652jiiGuvF95OtaiR/sr1T6jYboQlqaO6C05S9Ir0qR1lIW+Ie Kn4I3v3NXX5WpkoufzO/ea0UeaW6FAtL7WpQeYe1EYRPzrU9Zeh2G6blG/rGrJub RMAIdAu3xRlH9d0XarohYSa+32vjlVjed2DrMAhBt1Hd04NFtWSmyFgScwtIgzNR +Z4qydXvqUT00DSNjsS76gd32rqlDiAnPbl1KBwovACOHcjF9LBZ76sd8ygLrsdg s96O9WFkQqBIy4LVqJG6j9I0jFmXNAmI7gnbxN+evpgthF2wXPDnhzHuxtZHgMrM bdCyWy2xhpBc0CS30tcncyGPXncAeFYLuNdFBLtvaUlEAxfDbx4= =gQHy -----END PGP SIGNATURE----- --=-ot/ubNc/ufjn98q6vLwY--