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

[Michał Górny]

---
 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.
+
+
+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
+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.
+
+
+Authority Key vs gentoo-keys
+----------------------------
+The gentoo-keys project provides seed data that is sufficient to verify
+the authenticity of the keys.  However, this data uses entirely custom
+format and therefore requires special tooling to process.  This tooling
+has not been packaged for any other Linux distribution or operating
+system, and is non-trivial to install as unprivileged user.
+
+The Authority Key model is based entirely on built-in GnuPG features.
+It does not require any special tooling to run.  The necessary bootstrap
+can be done manually via GnuPG command-line facilities.  Eventually,
+even that may become unnecessary if the Authority Key is covered via
+web of trust.
+
+Furthermore, gentoo-keys seed data currently requires manual updates.
+The Authority Key system is automated, and therefore subject to smaller
+delays in operation.
+
+
+Developer coverage
+------------------
+In the original proposal, it was debated whether new developers should
+be subject to grace period during which their keys would not be signed.
+However, no arguments were brought to support such a period,
+and therefore the GLEP assumes all developers are covered as long
+as they are considered active Gentoo developers.
+
+Since only ``@gentoo.org`` e-mail addresses are under Gentoo control
+and developer identities outside the distribution are outside the scope
+of this project, only UIDs matching the respective developer addresses
+are signed.  This is meant to prevent the developers from forging
+somebody else's identity.
+
+The developers' real names are not verified.  Firstly, the purpose
+of this project is to establish association between keys and specific
+Gentoo developers, whose primary identification is the nickname used
+in Gentoo.  The exact real name is irrelevant to the validity in this
+context.  Secondly, comparing real names between LDAP and user
+identifiers would be non-trivial and most likely cause a number of
+developers being silently rejected due to e.g. modified name spelling.
+
+
+caff verification model
+-----------------------
+During the initial debate, using a model similar to Debian's caff tool
+was suggested.  In this model, new signatures are sent encrypted
+to the developers rather than uploaded straight to keyservers.
+Developers need to decrypt and add them to their keys themselves.
+[#CAFF]_
+
+The main purpose of the caff model is to assist users in verifying
+e-mail addresses of the UIDs they are about to sign.  By sending
+an encrypted e-mail, this model verifies that the recipient is both
+able to receive mail at a specific address and decrypt messages
+encrypted using the specified key.  Since the message contains complete
+signature ready to be imported, the key signing process can be completed
+entirely by the recipient and the sender does not need to be concerned
+past sending it.
+
+However, there seems to be no clear reason to employ this model here.
+A reasonable assumption can be made that if one is able to access
+the LDAP directory as a particular Gentoo developer, one is also able
+to access the developer's mailbox.  This considered, verifying
+the e-mail address in caff fashion is redundant.
+
+Furthermore, implementing this model increases complexity both server-
+and client-side.  The server would need to be entirely stateful to avoid
+sending duplicate mails, and at the same time it would need to permit
+re-requesting signature e-mails.  The developers would need to manually
+import the signature and send it to keyservers.
+
+It is quite probable that some of the less active developers would be
+permanently excluded by being unaware or uninterested in participating
+in the new system.  Furthermore, signature expirations would cause
+potentially extensive periods of key invalidity to occur (between
+signature expiration and import of the new one).  During those periods,
+users' ability to mail developers securely would be hindered.
+
+
+Dual-layer model
+----------------
+The dual-layer Authority Key model is established in order to combine
+security with needed automation.  The L1 Key provides higher level
+of security, at the cost of requiring manual operation.  The L2 Keys are
+suitable for automated use but that implies they're exposed to attacks.
+
+If the model was based on a single key and that key was compromised,
+the key would have to be revoked and replaced with a new one.  All users
+would have to fetch the new key and validate it independently to restore
+the developer key validity.
+
+Using two keys introduces a middle link in the trust chain that can be
+replaced easily.  Users trust the L1 Key which is unlikely to be
+compromised.  The trust on L2 Key is implicitly provided by the L1 Key,
+and users do not need to be specifically concerned about it.  If L2 Key
+is compromised, the Infrastructure developers can replace it and restore
+the trust via (non-compromised) L1 Key.  Users only have to fetch
+the new key and validity is restored.
+
+
+Security considerations
+-----------------------
+The user needs to be able to verify the authenticity of the L1 Key.
+This can be done in one of two ways:
+
+a. via comparing the fingerprint against the record on Gentoo website.
+   This relies on the security of Gentoo web servers, and the website
+   content repository.  From user side, authenticity relies on PKI
+   and/or DNSSEC, and possibly any other future HTTPS protection
+   mechanisms.
+
+b. via web of trust, provided the user trusts someone who verified
+   the key first.  In this case, the authenticity relies entirely
+   on the web of trust model, and is subject to attacks specific to it
+   (e.g. to wrongly trusting a malicious person).
+
+The L1 Key itself is protected from being compromised via current
+Infrastructure best practices.  At this moment, this involves password
+protection and offline storage.  If the key ever becomes compromised,
+the procedures involve revoking it and announcing the problem.
+
+The L2 Keys lack this kind of protection by design.  If they become
+compromised, the procedure involves revoking the key quickly
+and replacing it with a new one.
+
+In both cases, the revocation procedure relies on the user periodically
+refreshing keys against reliable sources.  Typically this involves using
+SKS keyservers over HKPS which in turn relies on PKI to prevent a third
+party from intercepting propagation of revocations.
+
+The validity of developer key UIDs is established via signatures made
+by the L2 Key.  If UIDs become no longer valid, the signatures are
+revoked in order to invalidate them.  This also relies on users
+periodically pulling keyservers for developer key updates.
+
+Additionally, signatures are made with one year expiration time.
+In the extremely unlikely case of scripts failing to revoke
+the particular signature, it will expire automatically.
+
+
+Backwards Compatibility
+=======================
+This proposal is established independently of existing solutions,
+and does not affect them.
+
+
+Reference Implementation
+========================
+The reference tooling for maintaining Authority Key signatures is
+published as gentoo-authority-key project.  [#GENTOO-AUTHORITY-KEY]_
+
+
+References
+==========
+.. [#KEY-BUNDLES] Directory listing including .gpg key bundles
+   (https://qa-reports.gentoo.org/output/)
+
+.. [#LDAP-GUIDE] Project:Infrastructure/LDAP Guide - Gentoo Wiki
+   (https://wiki.gentoo.org/wiki/Project:Infrastructure/LDAP_Guide)
+
+.. [#WWW-SIGNATURES] Release media signatures - Gentoo Linux
+   (https://www.gentoo.org/downloads/signatures/)
+
+.. [#KEY-PACKAGE] app-crypt/openpgp-keys-gentoo-release – Gentoo Packages
+   (https://packages.gentoo.org/packages/app-crypt/openpgp-keys-gentoo-release)
+
+.. [#GENTOO-KEYS] Project:Gentoo-keys - Gentoo Wiki
+   (https://wiki.gentoo.org/wiki/Project:Gentoo-keys)
+
+.. [#CAFF] caff - Debian Wiki
+   (https://wiki.debian.org/caff)
+
+.. [#GENTOO-AUTHORITY-KEY] mgorny/gentoo-authority-key: Script to
+   automatically sign developer keys using OpenPGP authority key
+   (https://github.com/mgorny/gentoo-authority-key)
+
+
+Copyright
+=========
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
+Unported License. To view a copy of this license, visit
+http://creativecommons.org/licenses/by-sa/3.0/.
-- 
2.21.0.rc2