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

[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@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.
+
+
+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

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

[Rich Freeman]

Overall, really good - just have a few comments for consideration
regarding expiration management.

On Sun, Feb 24, 2019 at 9:13 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> +Whenever an old signature expires, a new one is automatically created.

Unless this is just intended as loose wording, I'd suggest extending
expirations before keys expire, that way if keyservers are
inaccessible or users are offline there isn't as much exposure to a
period of non-validity.

Perhaps renew signatures a month prior to expiry, assuming the key has
remaining validity beyond the expiration date.

> +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.

If we're going to rotate the L2 keys, then likewise I'd consider
managing a period of overlapping validity.  That is:

1.  Generate new L2 key and sign with L1 when L2 has at least 30 days
expiry remaining.
2.  Re-sign all dev keys with new L2 key and use the L2 key
exclusively going forward.
3.  Wait 30 days.
4.  Revoke old L2 key, or allow to expire.  Destroy or archive old L2
private key.

This could be trivially implemented by simply not expiring the old L2
key and replacing it a month before it expires, and set the new L2
expiration in line with the rotation strategy.

Rationale:
a. Again, keyservers sometimes are offline, or users are offline, so
overlapping validity means that users are less exposed to invalid
signatures during an instantaneous transition period.
b. No need to continue to sign with the old L2 key during the
transition since users would get the new L2 key at the same time that
they would have gotten any new signatures made by the old key.

My comment is not intended to argue for/against the need for L2 key
rotation in the first place, just suggest that it be managed in a more
graceful manner if it is performed.

I also acknowledge that these comments might be more granular than
intended by the GLEP and suitably generic wording is fine, or perhaps
the original GLEP was already intended to be inclusive of this option.

-- 
Rich

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

[Michał Górny]

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

On Sun, 2019-02-24 at 09:38 -0500, Rich Freeman wrote:
> Overall, really good - just have a few comments for consideration
> regarding expiration management.
> 
> On Sun, Feb 24, 2019 at 9:13 AM Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > +Whenever an old signature expires, a new one is automatically created.
> 
> Unless this is just intended as loose wording, I'd suggest extending
> expirations before keys expire, that way if keyservers are
> inaccessible or users are offline there isn't as much exposure to a
> period of non-validity.
> 
> Perhaps renew signatures a month prior to expiry, assuming the key has
> remaining validity beyond the expiration date.

It's intended to be loose.  There's no reason to force specific
implementation details here; I just indicate that renewing is necessary.

> 
> > +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.
> 
> If we're going to rotate the L2 keys, then likewise I'd consider
> managing a period of overlapping validity.  That is:

This only means rotating as a result of revocation.  Which is not
something we're going to predict up front.

Well, technically we could have a replacement key prepared up front
and kept secure but, again, that doesn't belong in the GLEP.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alec Warner]

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

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?


> +
> +
> +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


> +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.


> +
> +
> +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
>
>
>

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

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

[Michał Górny]

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

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?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alec Warner]

[-- 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 --]

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 3756 bytes --]

Hi,

I know I am late but...

1) I still don't understand the motivation for this. What will
change/improve/be possible in future vs. status quo?

2) This sounds like a blackbox only a few people know/understand:

> +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.

However, the L1 key is critical, especially if all devs will sign that
key. E.g. this will allow people with access to L1 to establish a new
tree without the knowledge of everyone who signed the key but the new
tree will be able to issue new signatures and everyone will accept them
because L1 is trusted. Unacceptable. Process must be clear for
_everyone_. No blackbox.


> +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.

This is problematic. Nobody should ever sign something because it was
published somewhere. I know this will be a hard challenge but I believe
the L1 key can only be created if infra people will meet in person:

- This will guarantee that nobody will take a copy of the L1 key,
assuming we trust these people (maybe do this during a Gentoo conference
so other people can watch the ceremony).

- We will sign L1 only because it was signed by infra person X which we
met in person. E.g. nobody should sign L1 key who hasn't met anyone who
already signed that key. Because mgorny and antarus for example never
met somone else according to current WoT graph, trust anchor will
probably be robbat2 -> k_f -> ... for most people. But signing something
because you were asked to do so without *any* trust anchor should be a
no go.

My main criticisms, however, is that this system will create a false
sense of security (authenticity to be precise):

Let's say Gentoo has a developer named Bob.

Bob's local system will get compromised. Attacker will gain access to
Bob's SSH key and will also find Bob's Gentoo LDAP password.

With the SSH key, the attacker will be able to connect to
dev.gentoo.org. The LDAP password will allow the attacker to add or
replace Bob's GPG fingerprint.

Thanks to the new system, an automatic process will sign that new GPG key.

The attacker is now able to manipulate an ebuild for example and push
that change. If no one happens to review the commit for some reason and
notice the malicious change, attack will be successful, because the
commit has a valid signature.

That's basically status quo (see #1).

Once we detect the compromise, we would disable Bob's access and revoke
all signatures. But this doesn't matter anymore.

Also keep in mind that currently we only validate last commit. If
another developer will add his/her commit on top of the attacker's
change, the attacker's key doesn't matter anymore.

My point is, you cannot automate trust. Yes, if someone has to change
his/her key it will be a pain for everyone... but that's part of the
game. The difference would be that nobody would sign that new key the
attacker added to LDAP because it wasn't signed by Bob's previous key
everyone trusted. So everyone would ping Bob asking what's going on. If
this would be a legitimate key change, Bob would explain that (and
probably sign that new key with the old key or he would have to
establish a new WoT). If this wasn't a legitimate key change, we would
notice...

I am basically back at #1. Why do we need GLEP 79? It doesn't improve
anything for real aside adding a lot of complexity. Wrong?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Michał Górny]

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

On Sun, 2019-03-10 at 17:53 +0100, Thomas Deutschmann wrote:
> Hi,
> 
> I know I am late but...
> 
> 1) I still don't understand the motivation for this. What will
> change/improve/be possible in future vs. status quo?

The motivation is that it will let people easily verify keys used by
Gentoo developers (mentioning 'people actually committing to the Gentoo
systems').  The status quo is that users need to jump through hoops to
verify key used by a developer, e.g. by either meeting him or finding
his fingerprint via api.g.o.

> 2) This sounds like a blackbox only a few people know/understand:
> 
> > +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.
> 
> However, the L1 key is critical, especially if all devs will sign that
> key. E.g. this will allow people with access to L1 to establish a new
> tree without the knowledge of everyone who signed the key but the new
> tree will be able to issue new signatures and everyone will accept them
> because L1 is trusted. Unacceptable. Process must be clear for
> _everyone_. No blackbox.

I don't understand what you mean here.  It is inevitable that person
having access to L1 key will be able to divert the trust.  Ergo, we want
to protect the key just like we protect service keys.

If you mean that every developer should have access to L1 key, then
you're introducing over 150 attack vectors.  Not to mention the majority
of developers doesn't understand much of OpenPGP, nor cares to, so
any attacker could trivially find a developer who doesn't protect his
copy (or access) to the key.

There doesn't exist any solution that doesn't involve having at least
one person who could abuse the key.  We can't do anything without
putting trust in *someone*, and in this particular case Infra makes
sense because they need to be trusted for a dozen other reasons.

> > +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.
> 
> This is problematic. Nobody should ever sign something because it was
> published somewhere. I know this will be a hard challenge but I believe
> the L1 key can only be created if infra people will meet in person:
> 
> - This will guarantee that nobody will take a copy of the L1 key,
> assuming we trust these people (maybe do this during a Gentoo conference
> so other people can watch the ceremony).
> 
> - We will sign L1 only because it was signed by infra person X which we
> met in person. E.g. nobody should sign L1 key who hasn't met anyone who
> already signed that key. Because mgorny and antarus for example never
> met somone else according to current WoT graph, trust anchor will
> probably be robbat2 -> k_f -> ... for most people. But signing something
> because you were asked to do so without *any* trust anchor should be a
> no go.

This will render it impossible for a huge majority of users to use this
system.  Effectively, it will render the proposal useless.  Then, people
would still end up jumping through hoops to mark individual keys trusted
to be able to send encrypted mail or anything, and your 'craving' for
security is effectively reducing the actual security of user systems.

> My main criticisms, however, is that this system will create a false
> sense of security (authenticity to be precise):
> 
> Let's say Gentoo has a developer named Bob.
> 
> Bob's local system will get compromised. Attacker will gain access to
> Bob's SSH key and will also find Bob's Gentoo LDAP password.
> 
> With the SSH key, the attacker will be able to connect to
> dev.gentoo.org. The LDAP password will allow the attacker to add or
> replace Bob's GPG fingerprint.
> 
> Thanks to the new system, an automatic process will sign that new GPG key.
> 
> The attacker is now able to manipulate an ebuild for example and push
> that change. If no one happens to review the commit for some reason and
> notice the malicious change, attack will be successful, because the
> commit has a valid signature.
> 
> That's basically status quo (see #1).

Exactly.  Signing doesn't make any difference here.  Once the attacker
adds new fingerprint to LDAP, the system will accept his commits.  Both
rsync and git distribution will sign the resulting repository, and all
users will happily use it.

> Once we detect the compromise, we would disable Bob's access and revoke
> all signatures. But this doesn't matter anymore.
> 
> Also keep in mind that currently we only validate last commit. If
> another developer will add his/her commit on top of the attacker's
> change, the attacker's key doesn't matter anymore.

Yes, this is also true but still completely irrelevant to the proposal.

> My point is, you cannot automate trust. Yes, if someone has to change
> his/her key it will be a pain for everyone... but that's part of the
> game. The difference would be that nobody would sign that new key the
> attacker added to LDAP because it wasn't signed by Bob's previous key
> everyone trusted. So everyone would ping Bob asking what's going on. If
> this would be a legitimate key change, Bob would explain that (and
> probably sign that new key with the old key or he would have to
> establish a new WoT). If this wasn't a legitimate key change, we would
> notice...
> 
> I am basically back at #1. Why do we need GLEP 79? It doesn't improve
> anything for real aside adding a lot of complexity. Wrong?
> 

Yes, you are.  You've basically described everything that's completely
irrelevant to this GLEP, and now you dismiss it because it doesn't fix
problem that wasn't addressed here in the first place.

The point is that it adds some well-described way of determining which
keys are currently used by apparent Gentoo developers.  It's not perfect
but it's better than not having any reasonably accessible way at all. 
The GLEP describes the terms, and you are free not to use this key
if you don't agree with them.

Yes, if Gentoo systems suffer a heavy compromise then this system can be
abused.  However, it also provides a clear way of revoking the involved
signatures and/or keys.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alec Warner]

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

I will probably end up repeating a lot of what mgorny has said later, but
I'll try to be concise ;)

I want to start with a premise, which is that most users don't have a trust
web, and so saying things like "we should build a web this way" or "users
should use a web" is self-defeating, our target userbase doesn't have one.

On Sun, Mar 10, 2019 at 12:53 PM Thomas Deutschmann <whissi@gentoo.org>
wrote:

> Hi,
>
> I know I am late but...
>
> 1) I still don't understand the motivation for this. What will
> change/improve/be possible in future vs. status quo?
>
> 2) This sounds like a blackbox only a few people know/understand:
>

> > +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.
>
> However, the L1 key is critical, especially if all devs will sign that
> key. E.g. this will allow people with access to L1 to establish a new
> tree without the knowledge of everyone who signed the key but the new
> tree will be able to issue new signatures and everyone will accept them
> because L1 is trusted. Unacceptable. Process must be clear for
> _everyone_. No blackbox.
>

Currently infra can make the website do whatever it wants, so anyone
chaining to LE already trusts Infra implicitly. Most users use this method:
they go to the website, look up a fingerprint, import it, verify with it,
etc. They don't use the trustdb to make these decisions.


>
>
> > +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.
>
> This is problematic. Nobody should ever sign something because it was
> published somewhere. I know this will be a hard challenge but I believe
> the L1 key can only be created if infra people will meet in person:
>
> - This will guarantee that nobody will take a copy of the L1 key,
> assuming we trust these people (maybe do this during a Gentoo conference
> so other people can watch the ceremony).
>

We could do something like generate the L1 key in a nitrokey if you wanted.
It would be somewhat problematic to durably tie it to the hardware like
that, but it seems fairly straightforward and costs 50$. Watching the
'ceremony' at a conference is not sufficient to prevent key ex-filtration;
you have to trust the laptop, the code its running on, etc. As mgorny
notes, trust must be rooted somewhere in this model.

Maybe you could build some kind of weird multi-factor solution where e.g.:

robbat2 brings the laptop.
mgorny brings a USB stick with some OS on it
antarus brings the nitrokey

The likelihood that we can generate a key safely is likely high in that
environment. You still end up trusting all of us to not steal the key
somehow and obviously there are occasions when we need to use the key (e.g.
L2 key rotation) and all the same caveats apply to that use.


> - We will sign L1 only because it was signed by infra person X which we
> met in person. E.g. nobody should sign L1 key who hasn't met anyone who
> already signed that key. Because mgorny and antarus for example never
> met somone else according to current WoT graph, trust anchor will
> probably be robbat2 -> k_f -> ... for most people. But signing something
> because you were asked to do so without *any* trust anchor should be a
> no go.
>

I don't particularly disagree with this, but I also don't think signing the
L1 is a critical portion of the proposal.


>
> My main criticisms, however, is that this system will create a false
> sense of security (authenticity to be precise):
>

Like mgorny' I'm going to mostly ignore everything below, because its
unrelated to the proposal. I will assert there is one snag here:

1) I'm an existing Gentoo user.
2) I have a web of trust.
3) I verify the tip of tree with my web[0]

If I then participate in this proposal:
1) I would go to api.g.o and get the L1 FP
2) I'd import it into my web and trust it.
3) Suddenly I potentially trust a bunch more keys because I'm trusting the
L1 key.
4) Its plausible for a commit to be marked-bad with my pre-L1 web, but OK
in my L1 web, and I don't think there is a way to tell the difference.

The second outcome is bad for users who use their web to verify a tree and
its likely those users should *not* trust the L1 key[1].

[0] Since many committers are not in the web, I'm already skeptical, but
lets assume its possible.
[1] Now we get into more confusing situations where we have subwebs and
various trust-levels and I'm just not sure how that works out, or how the
software acts when there is a conflict. In theory I'd want two keyrings
here right, one is my "real web" that I trust more than the "L1 web" and if
the real one says its bad, and the L1 says its good, I should trust the
real one and ignore the L1. But since its challenging to validate all
commits with just the real web, I potentially need both webs to verify all
commits and the L1 is a simple way to say "hey all of these keys are Gentoo
keys."


> Let's say Gentoo has a developer named Bob.
>
> Bob's local system will get compromised. Attacker will gain access to
> Bob's SSH key and will also find Bob's Gentoo LDAP password.
>
> With the SSH key, the attacker will be able to connect to
> dev.gentoo.org. The LDAP password will allow the attacker to add or
> replace Bob's GPG fingerprint.
>
> Thanks to the new system, an automatic process will sign that new GPG key.
>
> The attacker is now able to manipulate an ebuild for example and push
> that change. If no one happens to review the commit for some reason and
> notice the malicious change, attack will be successful, because the
> commit has a valid signature.
>
> That's basically status quo (see #1).
>

> Once we detect the compromise, we would disable Bob's access and revoke
> all signatures. But this doesn't matter anymore.

Also keep in mind that currently we only validate last commit. If
> another developer will add his/her commit on top of the attacker's
> change, the attacker's key doesn't matter anymore.


> My point is, you cannot automate trust. Yes, if someone has to change
> his/her key it will be a pain for everyone... but that's part of the
> game. The difference would be that nobody would sign that new key the
> attacker added to LDAP because it wasn't signed by Bob's previous key
> everyone trusted. So everyone would ping Bob asking what's going on. If
> this would be a legitimate key change, Bob would explain that (and
> probably sign that new key with the old key or he would have to
> establish a new WoT). If this wasn't a legitimate key change, we would
> notice...
>
> I am basically back at #1. Why do we need GLEP 79? It doesn't improve
> anything for real aside adding a lot of complexity. Wrong?
>

The assertion is that most users don't use a web (and don't want to) and
for those users its a net improvement to trust the L1 key. If you already
use a web then the value in this proposal is diminished due to the extra
risk the L1 key poses for your trust db.

-A


>
>
> --
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>
>

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