[gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Michał Górny]

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

Hello,

Here's first draft of proposed GLEP for establishing a WoT inside
Gentoo.  It already incorporates some early feedback, so before you
start the usual shooting: making it obligatory wasn't my idea.

---

---
GLEP: 9999
Title: Gentoo OpenPGP web of trust
Author: Michał Górny <mgorny@gentoo.org>
Type: Standards Track
Status: Draft
Version: 1
Created: 2019-01-20
Last-Modified: 2019-01-31
Post-History: 2019-01-31
Content-Type: text/x-rst
---

Abstract
========

In this GLEP the current status of establishing an OpenPGP web of trust
between Gentoo developers is described, and an argument is made for
pushing it forward.  Advantages of a strong WoT are considered,
including its usefulness for sign-off real name verification.  Rules for
creating key signatures are established, and an example of signing
procedure is provided.


Motivation
==========

While Gentoo observes the status of OpenPGP web of trust for many years,
there never has been a proper push to get all developers covered by it
or even formalize the rules of signing one another's keys.  Apparently,
there are still many Gentoo developers who do not have their
``@gentoo.org`` UID signed by another active developer.  Historically
there were also cases of developers signing others' UIDs without
actually verifying their identity.  [#WOT-GRAPH]_ [#WOT-STATS]_

The web of trust is usually considered secondary to Gentoo's internal
trust system based on key fingerprints stored in LDAP and distributing
via the website.  While this system reliably covers all Gentoo
developers, it has three major drawbacks:

1. It is entirely customary and therefore requires customized software
   to use.  In other words, it's of limited usefulness to people outside
   Gentoo or does not work out of the box there.

2. At least in the current form, it is entirely limited to Gentoo
   developers.  As such, it does not facilitate trust between them
   and the outer world.

3. It relies on a centralized server whose authenticity is in turn
   proved via PKI.  This model is generally considered weak.

Even if this trust system is to stay being central to Gentoo's needs,
it should be beneficial for Gentoo developers start to improving
the OpenPGP web of trust, both for the purpose of improving Gentoo's
position in it and for the purpose of enabling better trust coverage
between Gentoo developers, users and other people.

Furthermore, the recent copyright policy established in GLEP 76
introduces the necessity of verifying real names of developers.  Given
that the Foundation wishes to avoid requesting document scans or other
form of direct verification, the identity verification required
for UID signing can also serve the needs of verifying the name
for Certificate of Origin sign-off purposes.  [#GLEP76]_


Specification
=============

Signature requirements
----------------------

As a final goal of this GLEP, each Gentoo developer will be required
to have at least one signature from another Gentoo developer or from
member of one of the partner communities present on their
``@gentoo.org`` UID.

Recruits will be required to obtain such a signature on one of their
user identifiers containing their real name before becoming Gentoo
developers.  After obtaining the ``@gentoo.org`` e-mail address, they
will be required to add it to their OpenPGP key and obtain a signature
on it as well before obtaining commit access (this requires only e-mail
exchange with previous signer).

Transitional (grandfathering) period will be provided based on two
milestones:

- newly joining developers will be required to have their key signed
  prior to joining starting 2019-10-01,

- all existing developers will be required to have their key signed
  starting 2020-07-01.

If necessity arises, the Council may defer the milestones and extend
the transitional period.


Key signing rules
-----------------

When signing an OpenPGP key belonging to another person, the following
rules need to be respected:

1. Sign only those user identifiers which you have successfully
   verified.  Do not sign all identifiers unless you have previously
   verified all of them.

2. For the purpose of Gentoo sign-off usage, the key must have
   an identifier consisting of the real name of a natural person
   (per GLEP 76) and the respective e-mail address to be used
   in ``Signed-off-by`` line.  In case of Gentoo developers, this e-mail
   address has to be their ``@gentoo.org`` address.
   
   Other user identifiers do not need to strictly follow those rules,
   and may be skipped for the purpose of Gentoo key signing.  However,
   you should follow the respective rules for verifying those kind
   of identifiers (e.g. XMPP UIDs should be signed after verifying
   the working XEP-0373 or similar encryption, keybase.io UIDs should
   follow appropriate keybase verification).  [#XEP-0373]_
   [#KEYBASE.IO]_

3. Before signing a user identifier, make sure to:

   a. Obtain a fingerprint of the person's primary key (for the purpose
      of verifying the authenticity of the key you're about to sign).
      Usually, a printed strip containing ``gpg --list-key`` output
      is used for this purpose.

   b. Verify the person's real name (at least for the user identifier
      used for copyright purposes).  This is usually done through
      verifying an identification document with photograph.  It is
      a good idea to ask for the document type earlier, and read on
      forgery protections used.

      In some cases, alternate methods of verifying the identity may be
      used if they provide equivalent or better level of reliability.
      This can include e.g. use of national online identification
      systems or bank transfers.

   c. Verify that the person has access to the corresponding e-mail
      address / web resource, e.g. by sending a block of randomly
      generated data and requesting sending it back, signed using
      the respective key.

4. Once you signed a single user identifier of a particular person, you
   can sign new user identifiers by just verifying the e-mail address
   without repeating identity verification (provided the new UIDs share
   the same real name).

5. If you have reasons to believe that the particular person has lost
   access to the respective e-mail address (e.g. due to retirement),
   that the real name is no longer valid or the user identifier became
   invalid for any other reason, you should revoke your previous
   signature on it.


Key signing partners
--------------------

In order to improve key signing accessibility to developers, Gentoo will
accept signatures made by members of partner communities.  The list
of partner communities will be maintained in Gentoo Wiki [TODO].  New
communities will be added to the list only if they have compatible key
signing rules and they agree to it.


Example key signing process (informative)
-----------------------------------------

Let's consider that Alice is planning to meet Bob and sign his OpenPGP
key.  In this section, we will only consider the process of signing
Bob's key from Alice's perspective.  Usually, at the same time Bob would
sign Alice's key — with an equivalent process.

Bob has printed the output of ``gpg --list-keys`` for his key, and gives
it to Alice.  It contains the following text::

    pub   rsa2048 2019-01-23 [SC] [expires: 2021-01-22]
          6CDE875E9CCF01D6E5691C9561FB7991B3D45B3C
    uid           [ultimate] Robert Someone <bob@example.com>
    uid           [ultimate] Robert Someone <bob2@example.org>
    sub   rsa2048 2019-01-23 [E] [expires: 2021-01-22]

Alice verifies the Bob's identity.  He gives her his ID card, stating::

    Given name: Robert
    Family name: Someone

Ideally, Alice would have known what kind of document to expected
and would have read up on verifying it.  After verifying that
the document looks legitimate, and the photograph reasonably matches
Bob, she has confirmed Bob's real name.

Afterwards, she prepares two chunks of random data, e.g. by doing::

    dd if=/dev/urandom bs=1k count=1 | base64

She sends the first of them to ``bob@example.com``, and the second one
to ``bob2@example.com``.  Bob replies by quoting the received chunk,
and signing his mail using his OpenPGP key.  Once Alice receives
the reply, she verifies the content and the fingerprint of primary key
corresponding to the signature.  If they match, she has confirmed Bob's
e-mail addresses.

At this point, she can sign both of Bob's UIDs.


Rationale
=========

Milestones
----------

The transitional period is provided so that developers currently missing
user signatures are given time to obtain them.  Initially, the period
is set to roughly one and half year but can be extended if the adoption
is problematic.

Additionally, a half as long transitional period is provided for new
developers.  This is meant to avoid blocking recruitment while the key
signing network is still being built.


Rules
-----

The rules aim to reiterate the common web of trust practices.  Firstly,
they emphasize the fact that signatures are done per user identifier
and not per key, and therefore each identifier signed needs to be
verified.  Appropriately, you don't have to sign all the user
identifiers immediately or at all.

The policy is focused around standard user identifiers, consisting
of a real name and an e-mail address.  In context of those, it requires
at least a single identifier that actually has a real name for GLEP 67
purposes.  It also indicates that there can be other kinds of user
identifiers that may require different verification rules.

The actual verification of each user identifier consists of confirming
three relevant parts: primary key fingerprint, real name and e-mail
address (or their equivalents in other kinds of user identifiers).

The primary key fingerprint is used to obtain the correct key to sign,
and to prevent a malicious third party from providing you with a forged
key.  Real name and e-mail verification is used to confirm
the authenticity of each user identifier being signed.  Use of random
data in e-mail makes it possible to clearly confirm that the same person
is both in possession of the e-mail address and the private keys.

Once an identity is verified once, there is no reason to verify it again
to sign further user identifiers using the same name.  This is helpful
e.g. when a person obtains new e-mail addresses, and wishes to get them
signed.  In that case, new signatures can be added after verifying
the e-mail address, and confirming match with the prior verified name.

Finally, since user identifier signatures are normally non-expiring
and therefore indicate perpetual trust, it is reasonable to revoke them
when the identifiers stop being valid.


Partner communities
-------------------

Both to improve global web of trust coverage, and to avoid requiring
developers to travel abroad to meet other Gentoo developers, the policy
accounts for establishing partnership with other communities using
OpenPGP.  Those partnerships will increase the chances that Gentoo
developers and recruits will be able to obtain a valid signature nearer
to their locality.

In order to maintain a reasonable quality of signatures, only
communities respecting similar rules will be accepted (e.g. verifying
identities of developers).  Additionally, the communities will be
contacted first to avoid adding them against their will.


Web of trust in other open source projects
------------------------------------------

Debian requires all developers to obtain a signature from at least two
existing developers before joining.  They also explicitly note
the necessity of verifying identity.  In case it's really impossible to
meet another developer, the Front Desk (equivalent of Recruiters) may
offer an alternative way of identification.  [#DEBIAN-IDENTIFICATION]_

NetBSD requires all applicants to sign the application with a key that
is already signed by at least one NetBSD developer.  [#NETBSD-PGP]_


Backwards Compatibility
=======================

Gentoo does not use any particular web of trust policy at the moment.
Not all of existing signatures conform to the new policy.  Therefore,
approving it is going to require, in some cases:

a. replacing non-conformant user identifiers,

b. revoking non-conformant signatures.

Naturally, those actions can only be carried off by cooperating key
owners.

The policy specifies transitional periods for developers whose keys are
not signed by anyone in the community yet.


Reference Implementation
========================

n/a


References
==========

.. [#WOT-GRAPH] Gentoo Dev Web of Trust (WoT)
   (https://qa-reports.gentoo.org/output/wot-graph.svg)

.. [#WOT-STATS] WoT Node Stats
   (https://qa-reports.gentoo.org/output/wot-stats.html)

.. [#GLEP76] GLEP 76: Copyright Policy
   (https://www.gentoo.org/glep/glep-0076.html)

.. [#XEP-0373] XEP-0373: OpenPGP for XMPP
   (https://xmpp.org/extensions/xep-0373.html)

.. [#KEYBASE.IO] Keybase
   (https://keybase.io/)

.. [#DEBIAN-IDENTIFICATION] Debian -- Step 2: Identification
   (https://www.debian.org/devel/join/nm-step2.en.html)

.. [#NETBSD-PGP] PGP Key Management Guide for NetBSD developers
   (https://www.netbsd.org/developers/pgp.html)


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


-- 
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: Gentoo OpenPGP web of trust

[Brian Evans]

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

On 1/31/2019 8:56 AM, Michał Górny wrote:

> 
> Signature requirements
> ----------------------
> 
> As a final goal of this GLEP, each Gentoo developer will be required
> to have at least one signature from another Gentoo developer or from
> member of one of the partner communities present on their
> ``@gentoo.org`` UID.

-1

I won't be able to accomplish this as I do not travel and have no
opportunities to meet with others. Plus, it's just downright awkward.
I'm sure there are other devs in this same situation.


Brian


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Matthew Thode]

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

On 19-01-31 14:56:48, Michał Górny wrote:
> Motivation
> ==========
> 
> While Gentoo observes the status of OpenPGP web of trust for many years,
> there never has been a proper push to get all developers covered by it
> or even formalize the rules of signing one another's keys.  Apparently,
> there are still many Gentoo developers who do not have their
> ``@gentoo.org`` UID signed by another active developer.  Historically
> there were also cases of developers signing others' UIDs without
> actually verifying their identity.  [#WOT-GRAPH]_ [#WOT-STATS]_
> 
> The web of trust is usually considered secondary to Gentoo's internal
> trust system based on key fingerprints stored in LDAP and distributing
> via the website.  While this system reliably covers all Gentoo
> developers, it has three major drawbacks:
> 
> 1. It is entirely customary and therefore requires customized software
>    to use.  In other words, it's of limited usefulness to people outside
>    Gentoo or does not work out of the box there.
s/customary/custom?
> 
> 2. At least in the current form, it is entirely limited to Gentoo
>    developers.  As such, it does not facilitate trust between them
>    and the outer world.
> 
> 3. It relies on a centralized server whose authenticity is in turn
>    proved via PKI.  This model is generally considered weak.
> 
> Even if this trust system is to stay being central to Gentoo's needs,
> it should be beneficial for Gentoo developers start to improving
> the OpenPGP web of trust, both for the purpose of improving Gentoo's
> position in it and for the purpose of enabling better trust coverage
> between Gentoo developers, users and other people.
> 
> Furthermore, the recent copyright policy established in GLEP 76
> introduces the necessity of verifying real names of developers.  Given
> that the Foundation wishes to avoid requesting document scans or other
> form of direct verification, the identity verification required
> for UID signing can also serve the needs of verifying the name
> for Certificate of Origin sign-off purposes.  [#GLEP76]_
> 

I don't see anything in glep 76 about requiring verification of the
signatures.  It's my view (as trustee) that assertation by the signer
that 'this is my signature' is sufficient.  Introducing more
verification should not be needed.  That said I do think switching to a
WoT model has some merit, it's just that the name verification is a
side benefit, not a primary reason for the switch.

> Backwards Compatibility
> =======================
> 
> Gentoo does not use any particular web of trust policy at the moment.
> Not all of existing signatures conform to the new policy.  Therefore,
> approving it is going to require, in some cases:
> 
> a. replacing non-conformant user identifiers,
> 
> b. revoking non-conformant signatures.
> 
> Naturally, those actions can only be carried off by cooperating key
> owners.
> 
> The policy specifies transitional periods for developers whose keys are
> not signed by anyone in the community yet.
> 

I do wonder about how this part will be enforced.


-- 
Matthew Thode

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Matthew Thode]

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

On 19-01-31 09:21:41, Brian Evans wrote:
> On 1/31/2019 8:56 AM, Michał Górny wrote:
> 
> > 
> > Signature requirements
> > ----------------------
> > 
> > As a final goal of this GLEP, each Gentoo developer will be required
> > to have at least one signature from another Gentoo developer or from
> > member of one of the partner communities present on their
> > ``@gentoo.org`` UID.
> 
> -1
> 
> I won't be able to accomplish this as I do not travel and have no
> opportunities to meet with others. Plus, it's just downright awkward.
> I'm sure there are other devs in this same situation.
> 

There is a section about alternatives though they were not specified
(and no examples given).

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 1/31/19 2:56 PM, Michał Górny wrote:
> Partner communities
> -------------------
> 
> Both to improve global web of trust coverage, and to avoid requiring
> developers to travel abroad to meet other Gentoo developers, the policy
> accounts for establishing partnership with other communities using
> OpenPGP.  Those partnerships will increase the chances that Gentoo
> developers and recruits will be able to obtain a valid signature nearer
> to their locality.
> 
> In order to maintain a reasonable quality of signatures, only
> communities respecting similar rules will be accepted (e.g. verifying
> identities of developers).  Additionally, the communities will be
> contacted first to avoid adding them against their will.

Just a partial comment at this point, but while I agree the partner
communities that we accept should be listed in wiki, I believe
addition/removal should be up to council if we make this mandatory.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Alec Warner]

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

On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@gentoo.org> wrote:

> Hello,
>
> Here's first draft of proposed GLEP for establishing a WoT inside
> Gentoo.  It already incorporates some early feedback, so before you
> start the usual shooting: making it obligatory wasn't my idea.
>
> ---
>
> ---
> GLEP: 9999
> Title: Gentoo OpenPGP web of trust
> Author: Michał Górny <mgorny@gentoo.org>
> Type: Standards Track
> Status: Draft
> Version: 1
> Created: 2019-01-20
> Last-Modified: 2019-01-31
> Post-History: 2019-01-31
> Content-Type: text/x-rst
> ---
>
> Abstract
> ========
>
> In this GLEP the current status of establishing an OpenPGP web of trust
> between Gentoo developers is described, and an argument is made for
> pushing it forward.  Advantages of a strong WoT are considered,
> including its usefulness for sign-off real name verification.  Rules for
> creating key signatures are established, and an example of signing
> procedure is provided.
>
>
> Motivation
> ==========
>
> While Gentoo observes the status of OpenPGP web of trust for many years,
> there never has been a proper push to get all developers covered by it
> or even formalize the rules of signing one another's keys.  Apparently,
> there are still many Gentoo developers who do not have their
> ``@gentoo.org`` UID signed by another active developer.  Historically
> there were also cases of developers signing others' UIDs without
> actually verifying their identity.  [#WOT-GRAPH]_ [#WOT-STATS]_
>
> The web of trust is usually considered secondary to Gentoo's internal
> trust system based on key fingerprints stored in LDAP and distributing
> via the website.  While this system reliably covers all Gentoo
> developers, it has three major drawbacks:
>
> 1. It is entirely customary and therefore requires customized software
>    to use.  In other words, it's of limited usefulness to people outside
>    Gentoo or does not work out of the box there.
>

> 2. At least in the current form, it is entirely limited to Gentoo
>    developers.  As such, it does not facilitate trust between them
>    and the outer world.
>

> 3. It relies on a centralized server whose authenticity is in turn
>    proved via PKI.  This model is generally considered weak.
>
> Even if this trust system is to stay being central to Gentoo's needs,
> it should be beneficial for Gentoo developers start to improving
> the OpenPGP web of trust, both for the purpose of improving Gentoo's
> position in it and for the purpose of enabling better trust coverage
> between Gentoo developers, users and other people.
>
> Furthermore, the recent copyright policy established in GLEP 76
> introduces the necessity of verifying real names of developers.  Given
> that the Foundation wishes to avoid requesting document scans or other
> form of direct verification, the identity verification required
> for UID signing can also serve the needs of verifying the name
> for Certificate of Origin sign-off purposes.  [#GLEP76]_
>
>
My main problem with the GLEP is that it seems to propose a WoT for a WoT's
sake and my question then becomes "why do we need a WoT?"

As in, what does a WoT enable the project to do that it cannot do now?

-A


>
> Specification
> =============
>
> Signature requirements
> ----------------------
>
> As a final goal of this GLEP, each Gentoo developer will be required
> to have at least one signature from another Gentoo developer or from
> member of one of the partner communities present on their
> ``@gentoo.org`` UID.
>
> Recruits will be required to obtain such a signature on one of their
> user identifiers containing their real name before becoming Gentoo
> developers.  After obtaining the ``@gentoo.org`` e-mail address, they
> will be required to add it to their OpenPGP key and obtain a signature
> on it as well before obtaining commit access (this requires only e-mail
> exchange with previous signer).
>
> Transitional (grandfathering) period will be provided based on two
> milestones:
>
> - newly joining developers will be required to have their key signed
>   prior to joining starting 2019-10-01,
>
> - all existing developers will be required to have their key signed
>   starting 2020-07-01.
>
> If necessity arises, the Council may defer the milestones and extend
> the transitional period.
>
>
> Key signing rules
> -----------------
>
> When signing an OpenPGP key belonging to another person, the following
> rules need to be respected:
>
> 1. Sign only those user identifiers which you have successfully
>    verified.  Do not sign all identifiers unless you have previously
>    verified all of them.
>
> 2. For the purpose of Gentoo sign-off usage, the key must have
>    an identifier consisting of the real name of a natural person
>    (per GLEP 76) and the respective e-mail address to be used
>    in ``Signed-off-by`` line.  In case of Gentoo developers, this e-mail
>    address has to be their ``@gentoo.org`` address.
>
>    Other user identifiers do not need to strictly follow those rules,
>    and may be skipped for the purpose of Gentoo key signing.  However,
>    you should follow the respective rules for verifying those kind
>    of identifiers (e.g. XMPP UIDs should be signed after verifying
>    the working XEP-0373 or similar encryption, keybase.io UIDs should
>    follow appropriate keybase verification).  [#XEP-0373]_
>    [#KEYBASE.IO]_
>
> 3. Before signing a user identifier, make sure to:
>
>    a. Obtain a fingerprint of the person's primary key (for the purpose
>       of verifying the authenticity of the key you're about to sign).
>       Usually, a printed strip containing ``gpg --list-key`` output
>       is used for this purpose.
>
>    b. Verify the person's real name (at least for the user identifier
>       used for copyright purposes).  This is usually done through
>       verifying an identification document with photograph.  It is
>       a good idea to ask for the document type earlier, and read on
>       forgery protections used.
>
>       In some cases, alternate methods of verifying the identity may be
>       used if they provide equivalent or better level of reliability.
>       This can include e.g. use of national online identification
>       systems or bank transfers.
>
>    c. Verify that the person has access to the corresponding e-mail
>       address / web resource, e.g. by sending a block of randomly
>       generated data and requesting sending it back, signed using
>       the respective key.
>
> 4. Once you signed a single user identifier of a particular person, you
>    can sign new user identifiers by just verifying the e-mail address
>    without repeating identity verification (provided the new UIDs share
>    the same real name).
>
> 5. If you have reasons to believe that the particular person has lost
>    access to the respective e-mail address (e.g. due to retirement),
>    that the real name is no longer valid or the user identifier became
>    invalid for any other reason, you should revoke your previous
>    signature on it.
>
>
> Key signing partners
> --------------------
>
> In order to improve key signing accessibility to developers, Gentoo will
> accept signatures made by members of partner communities.  The list
> of partner communities will be maintained in Gentoo Wiki [TODO].  New
> communities will be added to the list only if they have compatible key
> signing rules and they agree to it.
>
>
> Example key signing process (informative)
> -----------------------------------------
>
> Let's consider that Alice is planning to meet Bob and sign his OpenPGP
> key.  In this section, we will only consider the process of signing
> Bob's key from Alice's perspective.  Usually, at the same time Bob would
> sign Alice's key — with an equivalent process.
>
> Bob has printed the output of ``gpg --list-keys`` for his key, and gives
> it to Alice.  It contains the following text::
>
>     pub   rsa2048 2019-01-23 [SC] [expires: 2021-01-22]
>           6CDE875E9CCF01D6E5691C9561FB7991B3D45B3C
>     uid           [ultimate] Robert Someone <bob@example.com>
>     uid           [ultimate] Robert Someone <bob2@example.org>
>     sub   rsa2048 2019-01-23 [E] [expires: 2021-01-22]
>
> Alice verifies the Bob's identity.  He gives her his ID card, stating::
>
>     Given name: Robert
>     Family name: Someone
>
> Ideally, Alice would have known what kind of document to expected
> and would have read up on verifying it.  After verifying that
> the document looks legitimate, and the photograph reasonably matches
> Bob, she has confirmed Bob's real name.
>
> Afterwards, she prepares two chunks of random data, e.g. by doing::
>
>     dd if=/dev/urandom bs=1k count=1 | base64
>
> She sends the first of them to ``bob@example.com``, and the second one
> to ``bob2@example.com``.  Bob replies by quoting the received chunk,
> and signing his mail using his OpenPGP key.  Once Alice receives
> the reply, she verifies the content and the fingerprint of primary key
> corresponding to the signature.  If they match, she has confirmed Bob's
> e-mail addresses.
>
> At this point, she can sign both of Bob's UIDs.
>
>
> Rationale
> =========
>
> Milestones
> ----------
>
> The transitional period is provided so that developers currently missing
> user signatures are given time to obtain them.  Initially, the period
> is set to roughly one and half year but can be extended if the adoption
> is problematic.
>
> Additionally, a half as long transitional period is provided for new
> developers.  This is meant to avoid blocking recruitment while the key
> signing network is still being built.
>
>
> Rules
> -----
>
> The rules aim to reiterate the common web of trust practices.  Firstly,
> they emphasize the fact that signatures are done per user identifier
> and not per key, and therefore each identifier signed needs to be
> verified.  Appropriately, you don't have to sign all the user
> identifiers immediately or at all.
>
> The policy is focused around standard user identifiers, consisting
> of a real name and an e-mail address.  In context of those, it requires
> at least a single identifier that actually has a real name for GLEP 67
> purposes.  It also indicates that there can be other kinds of user
> identifiers that may require different verification rules.
>
> The actual verification of each user identifier consists of confirming
> three relevant parts: primary key fingerprint, real name and e-mail
> address (or their equivalents in other kinds of user identifiers).
>
> The primary key fingerprint is used to obtain the correct key to sign,
> and to prevent a malicious third party from providing you with a forged
> key.  Real name and e-mail verification is used to confirm
> the authenticity of each user identifier being signed.  Use of random
> data in e-mail makes it possible to clearly confirm that the same person
> is both in possession of the e-mail address and the private keys.
>
> Once an identity is verified once, there is no reason to verify it again
> to sign further user identifiers using the same name.  This is helpful
> e.g. when a person obtains new e-mail addresses, and wishes to get them
> signed.  In that case, new signatures can be added after verifying
> the e-mail address, and confirming match with the prior verified name.
>
> Finally, since user identifier signatures are normally non-expiring
> and therefore indicate perpetual trust, it is reasonable to revoke them
> when the identifiers stop being valid.
>
>
> Partner communities
> -------------------
>
> Both to improve global web of trust coverage, and to avoid requiring
> developers to travel abroad to meet other Gentoo developers, the policy
> accounts for establishing partnership with other communities using
> OpenPGP.  Those partnerships will increase the chances that Gentoo
> developers and recruits will be able to obtain a valid signature nearer
> to their locality.
>
> In order to maintain a reasonable quality of signatures, only
> communities respecting similar rules will be accepted (e.g. verifying
> identities of developers).  Additionally, the communities will be
> contacted first to avoid adding them against their will.
>
>
> Web of trust in other open source projects
> ------------------------------------------
>
> Debian requires all developers to obtain a signature from at least two
> existing developers before joining.  They also explicitly note
> the necessity of verifying identity.  In case it's really impossible to
> meet another developer, the Front Desk (equivalent of Recruiters) may
> offer an alternative way of identification.  [#DEBIAN-IDENTIFICATION]_
>
> NetBSD requires all applicants to sign the application with a key that
> is already signed by at least one NetBSD developer.  [#NETBSD-PGP]_
>
>
> Backwards Compatibility
> =======================
>
> Gentoo does not use any particular web of trust policy at the moment.
> Not all of existing signatures conform to the new policy.  Therefore,
> approving it is going to require, in some cases:
>
> a. replacing non-conformant user identifiers,
>
> b. revoking non-conformant signatures.
>
> Naturally, those actions can only be carried off by cooperating key
> owners.
>
> The policy specifies transitional periods for developers whose keys are
> not signed by anyone in the community yet.
>
>
> Reference Implementation
> ========================
>
> n/a
>
>
> References
> ==========
>
> .. [#WOT-GRAPH] Gentoo Dev Web of Trust (WoT)
>    (https://qa-reports.gentoo.org/output/wot-graph.svg)
>
> .. [#WOT-STATS] WoT Node Stats
>    (https://qa-reports.gentoo.org/output/wot-stats.html)
>
> .. [#GLEP76] GLEP 76: Copyright Policy
>    (https://www.gentoo.org/glep/glep-0076.html)
>
> .. [#XEP-0373] XEP-0373: OpenPGP for XMPP
>    (https://xmpp.org/extensions/xep-0373.html)
>
> .. [#KEYBASE.IO] Keybase
>    (https://keybase.io/)
>
> .. [#DEBIAN-IDENTIFICATION] Debian -- Step 2: Identification
>    (https://www.debian.org/devel/join/nm-step2.en.html)
>
> .. [#NETBSD-PGP] PGP Key Management Guide for NetBSD developers
>    (https://www.netbsd.org/developers/pgp.html)
>
>
> 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/.
>
>
> --
> Best regards,
> Michał Górny
>

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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Rich Freeman]

On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> 1. It is entirely customary and therefore requires customized software
>    to use.  In other words, it's of limited usefulness to people outside
>    Gentoo or does not work out of the box there.

This part could be addressed easily by having Gentoo create a signing
key, and automatically signing all dev keys based on LDAP using it.
Then users can trust that one key and inherit trust for the rest.

Users have to opt into the trust model by trusting somebody's key no
matter what.  No reason that couldn't be a centrally-managed one.

I'll also agree with the comment that physically interacting with
people is not all that easy.  There are many areas of the world where
FOSS developers are relatively uncommon, let alone Gentoo ones.
Unless those alternate organizations have VERY broad coverage (such as
an alternative of a notary recognized by any country or something like
that) you're still going to have issues.

> Verify the person's real name (at least for the user identifier
>      used for copyright purposes).  This is usually done through
>      verifying an identification document with photograph.  It is
>      a good idea to ask for the document type earlier, and read on
>      forgery protections used.

"usually"?  "identification document"?  Does this mean that an
appropriate method of verification is entirely up to individual
discretion?  If so that makes the process of getting every key signed
fairly trivial as long as two people have (in?)appropriately-rigorous
standards...

-- 
Rich

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 1/31/19 2:56 PM, Michał Górny wrote:
> Here's first draft of proposed GLEP for establishing a WoT inside
> Gentoo.  It already incorporates some early feedback, so before you
> start the usual shooting: making it obligatory wasn't my idea.

Well, I think the overall discussion for that is whether GLEP is the
right format or not. If it is a recommendation it is better suited for a
wiki article or similar, but if wanting to make it mandatory it should
go through the GLEP process.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 1/31/19 5:35 PM, Alec Warner wrote:
> 
> My main problem with the GLEP is that it seems to propose a WoT for
> a WoT's sake and my question then becomes "why do we need a WoT?"
> 
> As in, what does a WoT enable the project to do that it cannot do
> now?

There are multiple aspects to this, and I'm only commenting the way I
see it here.

being part of the WoT allows external parties to find a trust path to
gentoo developers, e.g when it comes to relying on communication in
various channels. This part could also be solved by infra running a
Gentoo Developer CA that signs all developers' Transferable Public Key
(TSP, aka public key).

More generally, being part of the WoT can demonstrate participation in
various developer communities. A user that is involved in various
upstream projects and familiar with them already can potentially be more
valuable as a developer for Gentoo, and can also potentially be a factor
for reduced tension between developers as they have demonstrated being
part of other communities already.

In addition comes a better certainty about the UID used for copyright in
signed-off-by, we as a distribution rely on this for both developers and
external contributors, and we need to demonstrate that we have taken
reasonable measures to ensure that what we add is unencumbered.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Alec Warner]

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

On Thu, Jan 31, 2019 at 3:31 PM Kristian Fiskerstrand <k_f@gentoo.org>
wrote:

> On 1/31/19 5:35 PM, Alec Warner wrote:
> >
> > My main problem with the GLEP is that it seems to propose a WoT for
> > a WoT's sake and my question then becomes "why do we need a WoT?"
> >
> > As in, what does a WoT enable the project to do that it cannot do
> > now?
>
> There are multiple aspects to this, and I'm only commenting the way I
> see it here.
>
> being part of the WoT allows external parties to find a trust path to
> gentoo developers, e.g when it comes to relying on communication in
> various channels. This part could also be solved by infra running a
> Gentoo Developer CA that signs all developers' Transferable Public Key
> (TSP, aka public key).
>

So we have a website that lists all of our developers and their gpg-fps
already. I realize that mgorny will object that this is a 'nonstandard
tool' or somesuch, but I think from my POV its a pretty straightforward
tool. Obviously it requires trusting www.gentoo.org and our CA (of which we
do not run our own, so it is letsencrypt, IIRC.)


>
> More generally, being part of the WoT can demonstrate participation in
> various developer communities. A user that is involved in various
> upstream projects and familiar with them already can potentially be more
> valuable as a developer for Gentoo, and can also potentially be a factor
> for reduced tension between developers as they have demonstrated being
> part of other communities already.
>

I agree this is a benefit, but is not sufficient to be mandatory.


>
> In addition comes a better certainty about the UID used for copyright in
> signed-off-by, we as a distribution rely on this for both developers and
> external contributors, and we need to demonstrate that we have taken
> reasonable measures to ensure that what we add is unencumbered.
>

I assume this is where the mandatory bits come in (and obviously where all
of the exciting politicking will happen around who owns how to assess and
address risk to "gentoo" and what "gentoo" is and so forth.)

To that end, is the WoT also mandatory for contributors? I didn't see
anything in the GLEP about it.

-A


> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 1/31/19 10:40 PM, Alec Warner wrote:
>> In addition comes a better certainty about the UID used for copyright in
>> signed-off-by, we as a distribution rely on this for both developers and
>> external contributors, and we need to demonstrate that we have taken
>> reasonable measures to ensure that what we add is unencumbered.
>>
> I assume this is where the mandatory bits come in (and obviously where all
> of the exciting politicking will happen around who owns how to assess and
> address risk to "gentoo" and what "gentoo" is and so forth.)
> 
> To that end, is the WoT also mandatory for contributors? I didn't see
> anything in the GLEP about it.

It would certainly be interesting to discuss whether it makes sense to
require contributors to be part of the strong set, indeed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Michael Orlitzky]

On 1/31/19 4:40 PM, Alec Warner wrote:
> 
> So we have a website that lists all of our developers and their gpg-fps 
> already. I realize that mgorny will object that this is a 'nonstandard 
> tool' or somesuch, but I think from my POV its a pretty straightforward 
> tool. Obviously it requires trusting www.gentoo.org 
> <http://www.gentoo.org> and our CA (of which we do not run our own, so 
> it is letsencrypt, IIRC.)
> 

The problem with the PKI is that even if LetsEncrypt is trustworthy, 
everyone else that you trust is not. If you're in whatever theocracy is 
in vogue for murdering its citizens this week, then you want to be sure 
that your government can't forge a certificate for www.gentoo.org (which 
says the "f" word a lot) on-the-fly. Of course, they all can. The list 
of trusted CAs in modern browsers is basically a "who's who" of the 
least trustworthy people on Earth.

With the web of trust, I am at least trusting someone who is trusting 
someone who is trusting someone who is trusting someone that I've met in 
person. It's a bit of a moot point so long as we distribute Gentoo 
itself over a channel that's secured by the PKI, but the two aren't 
equivalent.

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Rich Freeman]

On Thu, Jan 31, 2019 at 5:49 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/31/19 4:40 PM, Alec Warner wrote:
> >
> > So we have a website that lists all of our developers and their gpg-fps
> > already. I realize that mgorny will object that this is a 'nonstandard
> > tool' or somesuch, but I think from my POV its a pretty straightforward
> > tool. Obviously it requires trusting www.gentoo.org
> > <http://www.gentoo.org> and our CA (of which we do not run our own, so
> > it is letsencrypt, IIRC.)
> >
>
> The problem with the PKI is that even if LetsEncrypt is trustworthy,
> everyone else that you trust is not. If you're in whatever theocracy is
> in vogue for murdering its citizens this week, then you want to be sure
> that your government can't forge a certificate for www.gentoo.org (which
> says the "f" word a lot) on-the-fly. Of course, they all can. The list
> of trusted CAs in modern browsers is basically a "who's who" of the
> least trustworthy people on Earth.

These same governments print up the IDs the GLEP proposes that
developers verify.

Also, while governments like the US/EU might put a ton of security
features in those IDs, I suspect that quite a few governments issue
IDs with about as many anti-tamper features as a library card.  With a
WoT the chain is as strong as its weakest link.

> With the web of trust, I am at least trusting someone who is trusting
> someone who is trusting someone who is trusting someone that I've met in
> person.

You use the word "trust," but keep in mind the only thing that last
person is verifying is that:

1.  The person has an ID with a matching ID (issued by that theocracy
that murders its citizens).
2.  The person has control over the email address somebody presented
to the recruiters.  That would be the one that is reached via telecom
lines that go through the ISP controlled by that theocracy that
murders its citizens.

The person signing off on somebody's key won't be a close personal
friend of the applicant.  They won't have been their mentor for the
last six months.  They won't be on the same project, reviewing their
commits.  They'll be a random developer who just happens to live
somewhat near the applicant.  The actual mentors/etc would have been
in communication solely by email/IRC and will live on the other side
of the planet and probably will never actually meet the applicant in
person.

Now, perhaps the actual mentor will verify IDs/etc via webcam or
something like that, but you're still subject to the vulnerability of
the local government all the same, and if the mentor doesn't normally
interact via webcam they really won't know if the person on the other
end of the line is the person they've been interacting with all along.

If the threat model is state actors seeking to infiltrate Gentoo, then
the proposed methods are inadequate.  If the threat model is something
more likely such as misc vandals/etc, then we can probably relax
things further.

-- 
Rich

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Chris Reffett]

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

On 1/31/2019 8:56 AM, Michał Górny wrote:
> 
> 3. Before signing a user identifier, make sure to:
> 
>    b. Verify the person's real name (at least for the user identifier
>       used for copyright purposes).  This is usually done through
>       verifying an identification document with photograph.  It is
>       a good idea to ask for the document type earlier, and read on
>       forgery protections used.
> 
>       In some cases, alternate methods of verifying the identity may be
>       used if they provide equivalent or better level of reliability.
>       This can include e.g. use of national online identification
>       systems or bank transfers.
> 

I concur with the other comments people have made about this being an
unnecessarily restrictive burden, but let me pose a more philosophical
question: _why should proving my real name matter_? It's irrelevant that
I can prove my real name is in fact Chris Reffett, what's more important
is that there is somebody claiming the identity "creffett" whom people
(theoretically) trust as a developer. If I can't prove that that's my
real name, does that actually make a difference as to my trustworthiness
as a dev? It's the online "persona," if you will, that people trust, and
I don't see how verifying my name changes that. Now if I were trying to
use my PGP key as proof of my real-world identity, sure, it's a
reasonable concern, but I expect that if I'm involved in something like
that I would have to supply a scan of an identity document anyway.

And since I know someone will bring it up: yes, that is in fact my real
name. I'm just making a point.

-creffett


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 2/1/19 1:41 AM, Chris Reffett wrote:
> but let me pose a more philosophical
> question: _why should proving my real name matter_?

It matters in the context of copyright law.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 2/1/19 1:09 AM, Rich Freeman wrote:
> 1.  The person has an ID with a matching ID (issued by that theocracy
> that murders its citizens).

Whether the government murders its citizens or not isn't really relevant
for the discussions. We're not talking a political matter here, but
whether the identity can be confirmed. So as long as the RFID in the
passport can be read by a scanner and the information is good, it isn't
necessarily important whether that is from an oppressive regime. But
this is really getting close to an argumentum ad absurdium scenario.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Chris Reffett]

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


On 1/31/2019 7:42 PM, Kristian Fiskerstrand wrote:
> On 2/1/19 1:41 AM, Chris Reffett wrote:
>> but let me pose a more philosophical
>> question: _why should proving my real name matter_?
> 
> It matters in the context of copyright law.
> 
(IANAL, etc., etc.) At least in US copyright law, you may hold copyright
under a pseudonym, though it has different rules on the length of the
copyright and can cause issues with claiming ownership. Ref:
https://www.copyright.gov/fls/fl101.pdf

That said, though, I'm talking about the GPG key itself here, not my
commits, and I think that verification of real identity through WoT is
an unreasonably high bar for claiming copyright. As an analogy, I can
write a novel, self-publish, and claim copyright (without registering
the copyright, mind you - again, working in US law here, where copyright
is automatic on publication), and I never had to show ID to anyone - the
name on the cover gets the copyright. Why should my commits be any
different?

-creffett


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Rich Freeman]

On Thu, Jan 31, 2019 at 7:55 PM Chris Reffett <creffett@gentoo.org> wrote:
>
> On 1/31/2019 7:42 PM, Kristian Fiskerstrand wrote:
> > On 2/1/19 1:41 AM, Chris Reffett wrote:
> >> but let me pose a more philosophical
> >> question: _why should proving my real name matter_?
> >
> > It matters in the context of copyright law.
> >
>
> That said, though, I'm talking about the GPG key itself here, not my
> commits, and I think that verification of real identity through WoT is
> an unreasonably high bar for claiming copyright.

++

I think there are a lot of good reasons to require real names.
However, making that our policy and upholding it when we have cause to
think a name is false doesn't require us to rigorously check IDs.

Maybe for officers listed on filings for the Foundation it is more of a concern.

IMO Gentoo developers should simply be asked to provide their real
name, and to confirm that they are legally adults.  I don't think
we're doing anything that necessitates a higher level of due diligence
than that unless somebody actually brings a potential specific concern
to our attention.

-- 
Rich

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Sam Jorna (wraeth)]

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

On Friday, 1 February 2019 1:21:41 AM AEDT Brian Evans wrote:
> On 1/31/2019 8:56 AM, Michał Górny wrote:
> > Signature requirements
> > ----------------------
> > 
> > As a final goal of this GLEP, each Gentoo developer will be required
> > to have at least one signature from another Gentoo developer or from
> > member of one of the partner communities present on their
> > ``@gentoo.org`` UID.
> 
> -1
> 
> I won't be able to accomplish this as I do not travel and have no
> opportunities to meet with others. Plus, it's just downright awkward.
> I'm sure there are other devs in this same situation.

Just as a side-note to this, according to the Current Developers page[0], 
there are only three Gentoo developers listed as being in Australia including 
myself.

[0] https://www.gentoo.org/inside-gentoo/developers/

--
Sam Jorna (wraeth)
GPG ID: 0xD6180C26


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Michał Górny]

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

On Thu, 2019-01-31 at 09:21 -0500, Brian Evans wrote:
> On 1/31/2019 8:56 AM, Michał Górny wrote:
> 
> > 
> > Signature requirements
> > ----------------------
> > 
> > As a final goal of this GLEP, each Gentoo developer will be required
> > to have at least one signature from another Gentoo developer or from
> > member of one of the partner communities present on their
> > ``@gentoo.org`` UID.
> 
> -1
> 
> I won't be able to accomplish this as I do not travel and have no
> opportunities to meet with others. Plus, it's just downright awkward.
> I'm sure there are other devs in this same situation.
> 

The most commonly proposed alternative is identity verification via
video chat.  Would that also be unachievable for you?

It would be really nice to get some measure on how many people *really*
can't do it, rather than how many will oppose for the sake of opposing. 
It is funny how many of the people complaining today would actually
quickly get the needed signature if this was required from the start.

-- 
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: Gentoo OpenPGP web of trust

[Andreas K. Huettel]

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

> 
> I don't see anything in glep 76 about requiring verification of the
> signatures.  It's my view (as trustee) that assertation by the signer
> that 'this is my signature' is sufficient.

^ This. 

It's not our business to check IDs, and it's not our business to stalk people 
on google or facebook.

Now if someone says "Here's my name, and actually it is a fake name", then 
that is a reason to refuse commit rights or patch acceptance, and probably ask 
for some sort of verification when another name is then given. 

(That behaviour is roughly as intelligent as walking up to the security guy at 
the airport and claiming loudly "I have a bomb in my luggage.")

Apart from that, I dont think we should care.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Andreas K. Huettel]

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

Am Donnerstag, 31. Januar 2019, 18:33:25 CET schrieb Rich Freeman:
> On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@gentoo.org> wrote:
> > 1. It is entirely customary and therefore requires customized software
> > 
> >    to use.  In other words, it's of limited usefulness to people outside
> >    Gentoo or does not work out of the box there.
> 
> This part could be addressed easily by having Gentoo create a signing
> key, and automatically signing all dev keys based on LDAP using it.
> Then users can trust that one key and inherit trust for the rest.
> 
> Users have to opt into the trust model by trusting somebody's key no
> matter what.  No reason that couldn't be a centrally-managed one.

Nitpicking: Gentoo infra would only sign a @gentoo.org uid, and whether it 
should contain a name or not would need to be defined (and published somewhere 
as signature policy). 

But yes, that is a (different) obvious way to go.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Andreas K. Huettel]

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

Am Freitag, 1. Februar 2019, 02:56:29 CET schrieb Rich Freeman:
> On Thu, Jan 31, 2019 at 7:55 PM Chris Reffett <creffett@gentoo.org> wrote:
> > On 1/31/2019 7:42 PM, Kristian Fiskerstrand wrote:
> > > On 2/1/19 1:41 AM, Chris Reffett wrote:
> > >> but let me pose a more philosophical
> > >> question: _why should proving my real name matter_?
> > > 
> > > It matters in the context of copyright law.
> > 
> > That said, though, I'm talking about the GPG key itself here, not my
> > commits, and I think that verification of real identity through WoT is
> > an unreasonably high bar for claiming copyright.
> 
> ++
> 
> I think there are a lot of good reasons to require real names.
> However, making that our policy and upholding it when we have cause to
> think a name is false doesn't require us to rigorously check IDs.
> 
> Maybe for officers listed on filings for the Foundation it is more of a
> concern.
> 
> IMO Gentoo developers should simply be asked to provide their real
> name, and to confirm that they are legally adults.  I don't think
> we're doing anything that necessitates a higher level of due diligence
> than that unless somebody actually brings a potential specific concern
> to our attention.

++

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, toolchain, base-system, perl, libreoffice)

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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Michał Górny]

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

On Thu, 2019-01-31 at 12:33 -0500, Rich Freeman wrote:
> On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > 1. It is entirely customary and therefore requires customized software
> >    to use.  In other words, it's of limited usefulness to people outside
> >    Gentoo or does not work out of the box there.
> 
> This part could be addressed easily by having Gentoo create a signing
> key, and automatically signing all dev keys based on LDAP using it.
> Then users can trust that one key and inherit trust for the rest.
> 
> Users have to opt into the trust model by trusting somebody's key no
> matter what.  No reason that couldn't be a centrally-managed one.
> 
> I'll also agree with the comment that physically interacting with
> people is not all that easy.  There are many areas of the world where
> FOSS developers are relatively uncommon, let alone Gentoo ones.
> Unless those alternate organizations have VERY broad coverage (such as
> an alternative of a notary recognized by any country or something like
> that) you're still going to have issues.
> 
> > Verify the person's real name (at least for the user identifier
> >      used for copyright purposes).  This is usually done through
> >      verifying an identification document with photograph.  It is
> >      a good idea to ask for the document type earlier, and read on
> >      forgery protections used.
> 
> "usually"?  "identification document"?  Does this mean that an
> appropriate method of verification is entirely up to individual
> discretion?  If so that makes the process of getting every key signed
> fairly trivial as long as two people have (in?)appropriately-rigorous
> standards...
> 

I'm sorry, I keep forgetting that you can't rely on people in Gentoo
being mature and you need to specify everything as 'MUST' and 'MUST
NOT', or otherwise they are going to ignore the spirit of the policy
and violate in the worst way permitted by bending the wording.

-- 
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: Gentoo OpenPGP web of trust

[Cynede]

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

On Fri, 2019-02-01 at 13:47 +0100, Andreas K. Huettel wrote:
> > I don't see anything in glep 76 about requiring verification of the
> > signatures.  It's my view (as trustee) that assertation by the
> > signer
> > that 'this is my signature' is sufficient.
> 
> ^ This. 
> 
> It's not our business to check IDs, and it's not our business to
> stalk people 
> on google or facebook.
> 
> Now if someone says "Here's my name, and actually it is a fake name",
> then 
> that is a reason to refuse commit rights or patch acceptance, and
> probably ask 
> for some sort of verification when another name is then given. 
> 
> (That behaviour is roughly as intelligent as walking up to the
> security guy at 
> the airport and claiming loudly "I have a bomb in my luggage.")
> 
> Apart from that, I dont think we should care.
> 

I agree.

I'd like Gentoo to support pseudonyms (for the purposes of privacy) as
FSF projects does, and in that case ID/webcam verification with OpenPGP
keys being signed by members of trustee makes real sense. (probably
that could be off-topic here)


Cynede

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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Michał Górny]

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

On Thu, 2019-01-31 at 09:32 -0600, Matthew Thode wrote:
> On 19-01-31 14:56:48, Michał Górny wrote:
> > Motivation
> > ==========
> > 
> > While Gentoo observes the status of OpenPGP web of trust for many years,
> > there never has been a proper push to get all developers covered by it
> > or even formalize the rules of signing one another's keys.  Apparently,
> > there are still many Gentoo developers who do not have their
> > ``@gentoo.org`` UID signed by another active developer.  Historically
> > there were also cases of developers signing others' UIDs without
> > actually verifying their identity.  [#WOT-GRAPH]_ [#WOT-STATS]_
> > 
> > The web of trust is usually considered secondary to Gentoo's internal
> > trust system based on key fingerprints stored in LDAP and distributing
> > via the website.  While this system reliably covers all Gentoo
> > developers, it has three major drawbacks:
> > 
> > 1. It is entirely customary and therefore requires customized software
> >    to use.  In other words, it's of limited usefulness to people outside
> >    Gentoo or does not work out of the box there.
> 
> s/customary/custom?
> > 
> > 2. At least in the current form, it is entirely limited to Gentoo
> >    developers.  As such, it does not facilitate trust between them
> >    and the outer world.
> > 
> > 3. It relies on a centralized server whose authenticity is in turn
> >    proved via PKI.  This model is generally considered weak.
> > 
> > Even if this trust system is to stay being central to Gentoo's needs,
> > it should be beneficial for Gentoo developers start to improving
> > the OpenPGP web of trust, both for the purpose of improving Gentoo's
> > position in it and for the purpose of enabling better trust coverage
> > between Gentoo developers, users and other people.
> > 
> > Furthermore, the recent copyright policy established in GLEP 76
> > introduces the necessity of verifying real names of developers.  Given
> > that the Foundation wishes to avoid requesting document scans or other
> > form of direct verification, the identity verification required
> > for UID signing can also serve the needs of verifying the name
> > for Certificate of Origin sign-off purposes.  [#GLEP76]_
> > 
> 
> I don't see anything in glep 76 about requiring verification of the
> signatures.  It's my view (as trustee) that assertation by the signer
> that 'this is my signature' is sufficient.  Introducing more
> verification should not be needed.  That said I do think switching to a
> WoT model has some merit, it's just that the name verification is a
> side benefit, not a primary reason for the switch.

There's no plan to verify signatures of all contributors.  However,
I believe Gentoo developers should naturally go for higher standards. 
After all, if you don't care at all, why become a developer in the first
place?

> 
> > Backwards Compatibility
> > =======================
> > 
> > Gentoo does not use any particular web of trust policy at the moment.
> > Not all of existing signatures conform to the new policy.  Therefore,
> > approving it is going to require, in some cases:
> > 
> > a. replacing non-conformant user identifiers,
> > 
> > b. revoking non-conformant signatures.
> > 
> > Naturally, those actions can only be carried off by cooperating key
> > owners.
> > 
> > The policy specifies transitional periods for developers whose keys are
> > not signed by anyone in the community yet.
> > 
> 
> I do wonder about how this part will be enforced.
> 

It won't.

-- 
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: Gentoo OpenPGP web of trust

[Rich Freeman]

On Fri, Feb 1, 2019 at 9:17 AM Cynede <cynede@gentoo.org> wrote:
>
> I'd like Gentoo to support pseudonyms (for the purposes of privacy) as
> FSF projects does, and in that case ID/webcam verification with OpenPGP
> keys being signed by members of trustee makes real sense. (probably
> that could be off-topic here)

IMO this is fairly tangential to the WoT issue.

However, I'll point out the main issue with allowing pseudonyms is
that it basically reduces skin in the game.  People are probably less
likely to treat each other terribly if it will result in them never
getting another job.  On the other hand, people will behave better if
they know their reputation within Gentoo will translate into better
opportunities for them in the real world.

If somebody has a serious need for anonymity and safety, chances are
that some friendly government is already going to give them a new
name, but failing that perhaps exceptions could be made on an
individual basis.  I don't think the simple desire to remain anonymous
ought to be one of them.

-- 
Rich

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Brian Evans]

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

On 2/1/2019 1:57 AM, Michał Górny wrote:
> On Thu, 2019-01-31 at 09:21 -0500, Brian Evans wrote:
>> On 1/31/2019 8:56 AM, Michał Górny wrote:
>>
>>>
>>> Signature requirements
>>> ----------------------
>>>
>>> As a final goal of this GLEP, each Gentoo developer will be required
>>> to have at least one signature from another Gentoo developer or from
>>> member of one of the partner communities present on their
>>> ``@gentoo.org`` UID.
>>
>> -1
>>
>> I won't be able to accomplish this as I do not travel and have no
>> opportunities to meet with others. Plus, it's just downright awkward.
>> I'm sure there are other devs in this same situation.
>>
> 
> The most commonly proposed alternative is identity verification via
> video chat.  Would that also be unachievable for you?
> 
> It would be really nice to get some measure on how many people *really*
> can't do it, rather than how many will oppose for the sake of opposing. 

This is likely to be difficult if not impossible to accomplish.


> It is funny how many of the people complaining today would actually
> quickly get the needed signature if this was required from the start.

It's also funny how a few individuals are suddenly pushing this obscure
GPG "Web of Trust" that so few others care about. GnuPG is quite crude
and difficult to use and understand.

If this requirement becomes mandatory, my time will end at the 6 year
mark.  I cannot see myself ever being able to fulfill it, which is a shame.

This trend of creating difficult barriers is seemingly getting worse in
the last few proposals, both for users and developers.

I still say this is all a bad idea.

Brian


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 2/1/19 3:32 PM, Rich Freeman wrote:
> On Fri, Feb 1, 2019 at 9:17 AM Cynede <cynede@gentoo.org> wrote:
>>
>> I'd like Gentoo to support pseudonyms (for the purposes of privacy) as
>> FSF projects does, and in that case ID/webcam verification with OpenPGP
>> keys being signed by members of trustee makes real sense. (probably
>> that could be off-topic here)
> 
> IMO this is fairly tangential to the WoT issue.
> 
> However, I'll point out the main issue with allowing pseudonyms is
> that it basically reduces skin in the game.  People are probably less
> likely to treat each other terribly if it will result in them never
> getting another job.  On the other hand, people will behave better if
> they know their reputation within Gentoo will translate into better
> opportunities for them in the real world.
> 

Exactly, and that is only on the social element. Now what should we do
if we don't know the identities of our developers and there is a remote
code execution committed to our tree, obviously malicious, or someone
misuse access to information[N1]. This basically builds on the argument
of skin in the game, but it can be dragged further than your example.

Notes
[N1] Infra is in a special role here, but so are a lot of other projects
like comrel just to name another.
-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Kristian Fiskerstrand]

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

On 2/1/19 3:53 PM, Kristian Fiskerstrand wrote:
> Notes
> [N1] Infra is in a special role here, but so are a lot of other projects
> like comrel just to name another.

One alternative is of course to start gradually, and only require WoT
for certain roles; offhand I can think of; Infra, Comrel, Security,
Trustees and Council.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Rich Freeman]

On Fri, Feb 1, 2019 at 12:27 PM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
> On 2/1/19 3:53 PM, Kristian Fiskerstrand wrote:
> > Notes
> > [N1] Infra is in a special role here, but so are a lot of other projects
> > like comrel just to name another.
>
> One alternative is of course to start gradually, and only require WoT
> for certain roles; offhand I can think of; Infra, Comrel, Security,
> Trustees and Council.

Do we really want to tell developers they're not allowed to vote for a
particular candidate for Council because that candidate didn't prove
their identity?  IMO developers should be as free as possible to elect
whatever representatives they prefer.

Remember, Council members aren't just some kind of "privileged elite."
 They are also the way ordinary developers can exercise control over
all the other people who would otherwise be the "privileged elite" in
the absence of some kind of democratic representation.

I could see more of an argument for some of the other roles on the list.

-- 
Rich

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[desultory]

On 01/31/19 08:56, Michał Górny wrote:
> Hello,
> 
> Here's first draft of proposed GLEP for establishing a WoT inside
> Gentoo.  It already incorporates some early feedback, so before you
> start the usual shooting: making it obligatory wasn't my idea.
> 
Have some faith in your fellow developers, most don't tend to
communicates in ad hominem. Also, have some faith in yourself, it is not
a bad idea just because you posted it, it is a bad idea on it's own
(lack of) merit.

> ---
> 
> ---
> GLEP: 9999
> Title: Gentoo OpenPGP web of trust
> Author: Michał Górny <mgorny@gentoo.org>
> Type: Standards Track
> Status: Draft
> Version: 1
> Created: 2019-01-20
> Last-Modified: 2019-01-31
> Post-History: 2019-01-31
> Content-Type: text/x-rst
> ---
> 
> Abstract
> ========
> 
> In this GLEP the current status of establishing an OpenPGP web of trust
> between Gentoo developers is described, and an argument is made for
> pushing it forward.  Advantages of a strong WoT are considered,
> including its usefulness for sign-off real name verification.  Rules for
> creating key signatures are established, and an example of signing
> procedure is provided.
> 
> 
> Motivation
> ==========
> 
> While Gentoo observes the status of OpenPGP web of trust for many years,
> there never has been a proper push to get all developers covered by it
> or even formalize the rules of signing one another's keys.  Apparently,
> there are still many Gentoo developers who do not have their
> ``@gentoo.org`` UID signed by another active developer.  Historically
> there were also cases of developers signing others' UIDs without
> actually verifying their identity.  [#WOT-GRAPH]_ [#WOT-STATS]_
> 
I have been affiliated with Gentoo for over a decade now, I have never
needed to use my GPG keys for anything beyond verifying that they
worked. I have never needed to have them signed by anyone or anything
that wasn't automated. In over a decade.

> The web of trust is usually considered secondary to Gentoo's internal
> trust system based on key fingerprints stored in LDAP and distributing
> via the website.  While this system reliably covers all Gentoo
> developers, it has three major drawbacks:
> 
> 1. It is entirely customary and therefore requires customized software
>    to use.  In other words, it's of limited usefulness to people outside
>    Gentoo or does not work out of the box there.
> 
The custom software is, as one might infer, already in existence and
already operating, and has been for some time. Th role of the software
in question is to be *internally* useful, being useful to third parties
is outside of the problem space it is meant to address.

> 2. At least in the current form, it is entirely limited to Gentoo
>    developers.  As such, it does not facilitate trust between them
>    and the outer world.
> 
Which is entirely in keeping with its design and intended use; in short,
this not a bug..

> 3. It relies on a centralized server whose authenticity is in turn
>    proved via PKI.  This model is generally considered weak.
> 
However weak you may consider it to be, it has been sufficient for its
purpose for quite some time.

> Even if this trust system is to stay being central to Gentoo's needs,
> it should be beneficial for Gentoo developers start to improving
> the OpenPGP web of trust, both for the purpose of improving Gentoo's
> position in it and for the purpose of enabling better trust coverage
> between Gentoo developers, users and other people.
> 
And this is where things really start to go off the rails: "improving
Gentoo's position in" the web of trust rather strongly implies a deep
misunderstanding of how the system works and why it works the way it
does. Gaming a system that you do not understand is not likely to go well.
> Furthermore, the recent copyright policy established in GLEP 76
> introduces the necessity of verifying real names of developers.  Given
> that the Foundation wishes to avoid requesting document scans or other
> form of direct verification, the identity verification required
> for UID signing can also serve the needs of verifying the name
> for Certificate of Origin sign-off purposes.  [#GLEP76]_
> 
No, it doesn't. GLEP 76 makes the assertion that "The sign-off must
contain the committer's legal name as a natural person, i.e., the name
that would appear in a government issued document.", it does not
prescribe institutional confirmation of that "legal name as a natural
person". The implication is, at least if one is to read the document as
written, that the individual signing off on the commit is affirming that
they are using their "legal name as a natural person".
> 
> Specification
> =============
> 
> Signature requirements
> ----------------------
> 
> As a final goal of this GLEP, each Gentoo developer will be required
> to have at least one signature from another Gentoo developer or from
> member of one of the partner communities present on their
> ``@gentoo.org`` UID.
> > Recruits will be required to obtain such a signature on one of their
> user identifiers containing their real name before becoming Gentoo
> developers.  After obtaining the ``@gentoo.org`` e-mail address, they
> will be required to add it to their OpenPGP key and obtain a signature
> on it as well before obtaining commit access (this requires only e-mail
> exchange with previous signer).
> 
> Transitional (grandfathering) period will be provided based on two
> milestones:
> 
> - newly joining developers will be required to have their key signed
>   prior to joining starting 2019-10-01,
> 
> - all existing developers will be required to have their key signed
>   starting 2020-07-01.
> 
> If necessity arises, the Council may defer the milestones and extend
> the transitional period.
> 
> 
> Key signing rules
> -----------------
> 
> When signing an OpenPGP key belonging to another person, the following
> rules need to be respected:
> 
> 1. Sign only those user identifiers which you have successfully
>    verified.  Do not sign all identifiers unless you have previously
>    verified all of them.
> 
This seems to logically conflict with point 4.

> 2. For the purpose of Gentoo sign-off usage, the key must have
>    an identifier consisting of the real name of a natural person
>    (per GLEP 76) and the respective e-mail address to be used
>    in ``Signed-off-by`` line.  In case of Gentoo developers, this e-mail
>    address has to be their ``@gentoo.org`` address.
>    
>    Other user identifiers do not need to strictly follow those rules,
>    and may be skipped for the purpose of Gentoo key signing.  However,
>    you should follow the respective rules for verifying those kind
>    of identifiers (e.g. XMPP UIDs should be signed after verifying
>    the working XEP-0373 or similar encryption, keybase.io UIDs should
>    follow appropriate keybase verification).  [#XEP-0373]_
>    [#KEYBASE.IO]_
> 
> 3. Before signing a user identifier, make sure to:
> 
>    a. Obtain a fingerprint of the person's primary key (for the purpose
>       of verifying the authenticity of the key you're about to sign).
>       Usually, a printed strip containing ``gpg --list-key`` output
>       is used for this purpose.
> 
>    b. Verify the person's real name (at least for the user identifier
>       used for copyright purposes).  This is usually done through
>       verifying an identification document with photograph.  It is
>       a good idea to ask for the document type earlier, and read on
>       forgery protections used.
> 
Are you, in the general sense regarding the authors of this proposal,
seriously suggesting that random developers should become self-educated
expert identity document verifiers? This seems... questionably plausible.

>       In some cases, alternate methods of verifying the identity may be
>       used if they provide equivalent or better level of reliability.
>       This can include e.g. use of national online identification
>       systems or bank transfers.
> 
How, exactly, is a bank transfer a better means of establishing ones
"legal name as a natural person"?

>    c. Verify that the person has access to the corresponding e-mail
>       address / web resource, e.g. by sending a block of randomly
>       generated data and requesting sending it back, signed using
>       the respective key.
> 
The specific requirement for "randomly generated data" is pointless in
any realistic scenario.

> 4. Once you signed a single user identifier of a particular person, you
>    can sign new user identifiers by just verifying the e-mail address
>    without repeating identity verification (provided the new UIDs share
>    the same real name).
> 
> 5. If you have reasons to believe that the particular person has lost
>    access to the respective e-mail address (e.g. due to retirement),
>    that the real name is no longer valid or the user identifier became
>    invalid for any other reason, you should revoke your previous
>    signature on it.
> 
Revoking "trust" upon retirement, when the identity would be
functionally disabled with respect to Gentoo regardless, seems
pointless. Revoking "trust" upon legal name change is logically
pointless. Given the recommendation to create and retain a revocation
certificate for PGP keys, recommending that "trust" be revoked by others
is arguably redundant. [GLEP63]

> 
> Key signing partners
> --------------------
> 
> In order to improve key signing accessibility to developers, Gentoo will
> accept signatures made by members of partner communities.  The list
> of partner communities will be maintained in Gentoo Wiki [TODO].  New
> communities will be added to the list only if they have compatible key
> signing rules and they agree to it.
> 
Even if only for the sake of general example, outside of the proposal
itself, there really should be some indication of what "partner
communities" are being considered.

> 
> Example key signing process (informative)
> -----------------------------------------
> 
> Let's consider that Alice is planning to meet Bob and sign his OpenPGP
> key.  In this section, we will only consider the process of signing
> Bob's key from Alice's perspective.  Usually, at the same time Bob would
> sign Alice's key — with an equivalent process.
> 
> Bob has printed the output of ``gpg --list-keys`` for his key, and gives
> it to Alice.  It contains the following text::
> 
>     pub   rsa2048 2019-01-23 [SC] [expires: 2021-01-22]
>           6CDE875E9CCF01D6E5691C9561FB7991B3D45B3C
>     uid           [ultimate] Robert Someone <bob@example.com>
>     uid           [ultimate] Robert Someone <bob2@example.org>
>     sub   rsa2048 2019-01-23 [E] [expires: 2021-01-22]
> 
> Alice verifies the Bob's identity.  He gives her his ID card, stating::
> 
>     Given name: Robert
>     Family name: Someone
> 
> Ideally, Alice would have known what kind of document to expected
> and would have read up on verifying it.  After verifying that
> the document looks legitimate, and the photograph reasonably matches
> Bob, she has confirmed Bob's real name.
> 
Again, this is, according to the supposed "threat model" (ie people who
are using false identities and have even the slightest degree of
competence in that area) expecting a degree of expertise which is
unrealistic.

> Afterwards, she prepares two chunks of random data, e.g. by doing::
> 
>     dd if=/dev/urandom bs=1k count=1 | base64
> 
> She sends the first of them to ``bob@example.com``, and the second one
> to ``bob2@example.com``.  Bob replies by quoting the received chunk,
> and signing his mail using his OpenPGP key.  Once Alice receives
> the reply, she verifies the content and the fingerprint of primary key
> corresponding to the signature.  If they match, she has confirmed Bob's
> e-mail addresses.
> 
> At this point, she can sign both of Bob's UIDs.
> 
> 
> Rationale
> =========
> 
> Milestones
> ----------
> 
> The transitional period is provided so that developers currently missing
> user signatures are given time to obtain them.  Initially, the period
> is set to roughly one and half year but can be extended if the adoption
> is problematic.
> 
> Additionally, a half as long transitional period is provided for new
> developers.  This is meant to avoid blocking recruitment while the key
> signing network is still being built.
> 
Given that Gentoo is perpetually understaffed in various areas, and the
single issue that most often comes up as a reason for people to not join
and take a more active role is that it involves too much pointless work
to get their commit bit set, this proposal seeks to require pointless
work which many would out of principle not do and others are simply
unable to actually comply with. This seems sub-optimal.

> 
> Rules
> -----
> 
> The rules aim to reiterate the common web of trust practices.  Firstly,
> they emphasize the fact that signatures are done per user identifier
> and not per key, and therefore each identifier signed needs to be
> verified.  Appropriately, you don't have to sign all the user
> identifiers immediately or at all.
> 
> The policy is focused around standard user identifiers, consisting
> of a real name and an e-mail address.  In context of those, it requires
> at least a single identifier that actually has a real name for GLEP 67
GLEP 76 [GLEP76], GLEP 67 [GLEP67] seems at most tangentially related.

> purposes.  It also indicates that there can be other kinds of user
> identifiers that may require different verification rules.
> 
> The actual verification of each user identifier consists of confirming
> three relevant parts: primary key fingerprint, real name and e-mail
> address (or their equivalents in other kinds of user identifiers).
> 
> The primary key fingerprint is used to obtain the correct key to sign,
> and to prevent a malicious third party from providing you with a forged
> key.  Real name and e-mail verification is used to confirm
> the authenticity of each user identifier being signed.  Use of random
> data in e-mail makes it possible to clearly confirm that the same person
> is both in possession of the e-mail address and the private keys.
> 
The randomness in the "random data" is not required to function as
claimed, simply using different data, per user, suffices.

> Once an identity is verified once, there is no reason to verify it again
> to sign further user identifiers using the same name.  This is helpful
> e.g. when a person obtains new e-mail addresses, and wishes to get them
> signed.  In that case, new signatures can be added after verifying
> the e-mail address, and confirming match with the prior verified name.
> 
Functionally, this appear to be counter to point 1, above.

> Finally, since user identifier signatures are normally non-expiring
> and therefore indicate perpetual trust, it is reasonable to revoke them
> when the identifiers stop being valid.
> 
Arguably reasonable to recommend, generally pointless in practice.

> 
> Partner communities
> -------------------
> 
> Both to improve global web of trust coverage, and to avoid requiring
> developers to travel abroad to meet other Gentoo developers, the policy
> accounts for establishing partnership with other communities using
> OpenPGP.  Those partnerships will increase the chances that Gentoo
> developers and recruits will be able to obtain a valid signature nearer
> to their locality.
> 
> In order to maintain a reasonable quality of signatures, only
> communities respecting similar rules will be accepted (e.g. verifying
> identities of developers).  Additionally, the communities will be
> contacted first to avoid adding them against their will.
> 
> 
> Web of trust in other open source projects
> ------------------------------------------
> 
> Debian requires all developers to obtain a signature from at least two
> existing developers before joining.  They also explicitly note
> the necessity of verifying identity.  In case it's really impossible to
> meet another developer, the Front Desk (equivalent of Recruiters) may
> offer an alternative way of identification.  [#DEBIAN-IDENTIFICATION]_
> 
> NetBSD requires all applicants to sign the application with a key that
> is already signed by at least one NetBSD developer.  [#NETBSD-PGP]_
> 
Bother are statements that they have such requirements, neither
addresses any benefit from them. As such, this section is pointless.

> 
> Backwards Compatibility
> =======================
> 
> Gentoo does not use any particular web of trust policy at the moment.
> Not all of existing signatures conform to the new policy.  Therefore,
> approving it is going to require, in some cases:
> 
> a. replacing non-conformant user identifiers,
> 
> b. revoking non-conformant signatures.
> 
> Naturally, those actions can only be carried off by cooperating key
> owners.
> 
> The policy specifies transitional periods for developers whose keys are
> not signed by anyone in the community yet.
> 
The policy makes no effort to describe what would happen to developers
who, for whatever reason, were not compliant by the end of the proposed
transition period. This has been, by multiple people in this thread,
inferred to indicate that they will be forcibly retired Leaving what
would appear to be fundamental concerns to inference is sub-optimal.

> 
> Reference Implementation
> ========================
> 
> n/a
> 
> 
> References
> ==========
> 
> .. [#WOT-GRAPH] Gentoo Dev Web of Trust (WoT)
>    (https://qa-reports.gentoo.org/output/wot-graph.svg)
> 
> .. [#WOT-STATS] WoT Node Stats
>    (https://qa-reports.gentoo.org/output/wot-stats.html)
> 
> .. [#GLEP76] GLEP 76: Copyright Policy
>    (https://www.gentoo.org/glep/glep-0076.html)
> 
> .. [#XEP-0373] XEP-0373: OpenPGP for XMPP
>    (https://xmpp.org/extensions/xep-0373.html)
> 
> .. [#KEYBASE.IO] Keybase
>    (https://keybase.io/)
> 
> .. [#DEBIAN-IDENTIFICATION] Debian -- Step 2: Identification
>    (https://www.debian.org/devel/join/nm-step2.en.html)
> 
> .. [#NETBSD-PGP] PGP Key Management Guide for NetBSD developers
>    (https://www.netbsd.org/developers/pgp.html)
> 
> 
> 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/.
> 
> 

[GLEP63] https://www.gentoo.org/glep/glep-0063.html
[GLEP67] https://www.gentoo.org/glep/glep-0067.html
[GLEP76] https://www.gentoo.org/glep/glep-0076.html

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[desultory]

On 02/01/19 08:25, Michał Górny wrote:
> On Thu, 2019-01-31 at 12:33 -0500, Rich Freeman wrote:
>> On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@gentoo.org> wrote:
>>>
>>> 1. It is entirely customary and therefore requires customized software
>>>    to use.  In other words, it's of limited usefulness to people outside
>>>    Gentoo or does not work out of the box there.
>>
>> This part could be addressed easily by having Gentoo create a signing
>> key, and automatically signing all dev keys based on LDAP using it.
>> Then users can trust that one key and inherit trust for the rest.
>>
>> Users have to opt into the trust model by trusting somebody's key no
>> matter what.  No reason that couldn't be a centrally-managed one.
>>
>> I'll also agree with the comment that physically interacting with
>> people is not all that easy.  There are many areas of the world where
>> FOSS developers are relatively uncommon, let alone Gentoo ones.
>> Unless those alternate organizations have VERY broad coverage (such as
>> an alternative of a notary recognized by any country or something like
>> that) you're still going to have issues.
>>
>>> Verify the person's real name (at least for the user identifier
>>>      used for copyright purposes).  This is usually done through
>>>      verifying an identification document with photograph.  It is
>>>      a good idea to ask for the document type earlier, and read on
>>>      forgery protections used.
>>
>> "usually"?  "identification document"?  Does this mean that an
>> appropriate method of verification is entirely up to individual
>> discretion?  If so that makes the process of getting every key signed
>> fairly trivial as long as two people have (in?)appropriately-rigorous
>> standards...
>>
> 
> I'm sorry, I keep forgetting that you can't rely on people in Gentoo
> being mature and you need to specify everything as 'MUST' and 'MUST
> NOT', or otherwise they are going to ignore the spirit of the policy
> and violate in the worst way permitted by bending the wording.
> 
You started this thread with what distinctly appeared to be a plea to
avoid ad hominem attacks, just to turn around make make them yourself.
Do, kindly, stop it.

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[desultory]

On 02/01/19 01:57, Michał Górny wrote:
> On Thu, 2019-01-31 at 09:21 -0500, Brian Evans wrote:
>> On 1/31/2019 8:56 AM, Michał Górny wrote:
>>
>>>
>>> Signature requirements
>>> ----------------------
>>>
>>> As a final goal of this GLEP, each Gentoo developer will be required
>>> to have at least one signature from another Gentoo developer or from
>>> member of one of the partner communities present on their
>>> ``@gentoo.org`` UID.
>>
>> -1
>>
>> I won't be able to accomplish this as I do not travel and have no
>> opportunities to meet with others. Plus, it's just downright awkward.
>> I'm sure there are other devs in this same situation.
>>
> 
> The most commonly proposed alternative is identity verification via
> video chat.  Would that also be unachievable for you?
> 
> It would be really nice to get some measure on how many people *really*
> can't do it, rather than how many will oppose for the sake of opposing. 
> It is funny how many of the people complaining today would actually
> quickly get the needed signature if this was required from the start.
> 
I, for one, am a member of both sets: I neither reasonably could nor
would I if I reasonably could. In context [GLEP76], the proposed policy
is, by all appearances, pointless make work for the sake of buzzword bingo.

[GLEP76] https://www.gentoo.org/glep/glep-0076.html

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[desultory]

On 02/01/19 07:47, Andreas K. Huettel wrote:
>>
>> I don't see anything in glep 76 about requiring verification of the
>> signatures.  It's my view (as trustee) that assertation by the signer
>> that 'this is my signature' is sufficient.
> 
> ^ This. 
> 
> It's not our business to check IDs, and it's not our business to stalk people 
> on google or facebook.
> 
True, even according to GLEP 76.

> Now if someone says "Here's my name, and actually it is a fake name", then 
> that is a reason to refuse commit rights or patch acceptance, and probably ask 
> for some sort of verification when another name is then given. 
> 
False, though that falsehood drove acceptance of GLEP 76.

> (That behaviour is roughly as intelligent as walking up to the security guy at 
> the airport and claiming loudly "I have a bomb in my luggage.")
> As with your previous assertion, this is false, it is also pointlessly
hyperbolic.

> Apart from that, I dont think we should care.
>

Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust

[Rich Freeman]

On Sat, Feb 2, 2019 at 12:55 AM desultory <desultory@gentoo.org> wrote:
>
> On 02/01/19 08:25, Michał Górny wrote:
> > On Thu, 2019-01-31 at 12:33 -0500, Rich Freeman wrote:
> >> On Thu, Jan 31, 2019 at 8:56 AM Michał Górny <mgorny@gentoo.org> wrote:
> >>
> >>> Verify the person's real name (at least for the user identifier
> >>>      used for copyright purposes).  This is usually done through
> >>>      verifying an identification document with photograph.  It is
> >>>      a good idea to ask for the document type earlier, and read on
> >>>      forgery protections used.
> >>
> >> "usually"?  "identification document"?  Does this mean that an
> >> appropriate method of verification is entirely up to individual
> >> discretion?  If so that makes the process of getting every key signed
> >> fairly trivial as long as two people have (in?)appropriately-rigorous
> >> standards...
> >
> > I'm sorry, I keep forgetting that you can't rely on people in Gentoo
> > being mature and you need to specify everything as 'MUST' and 'MUST
> > NOT', or otherwise they are going to ignore the spirit of the policy
> > and violate in the worst way permitted by bending the wording.
> >
> You started this thread with what distinctly appeared to be a plea to
> avoid ad hominem attacks, just to turn around make make them yourself.
> Do, kindly, stop it.

Neither of our comments were helpful here.  I made a
passive-aggressive post out of emotion and mgorny made a provoked
passive-aggressive reply (which is why we shouldn't be communicating
this way in the first place).  In both cases the tone distracted from
the gist of the points:

1.  The standards for identification are somewhat subjective and will
necessarily vary from individual to individual.  You actually phrased
this concern better in your reply, and perhaps I might have done the
same if I had taken more time to compose myself better.
2.  Mgorny's point is that in practice well-intending identity
verifiers are probably going to be good enough at getting the job
done.  I agree, though mainly because I don't think it is important
that the job be done at all.

-- 
Rich