From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D7778138334 for ; Thu, 31 Jan 2019 16:36:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03D0AE0B20; Thu, 31 Jan 2019 16:36:04 +0000 (UTC) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 46AA5E0B0E for ; Thu, 31 Jan 2019 16:36:03 +0000 (UTC) Received: by mail-lf1-x12f.google.com with SMTP id p6so2843210lfc.1 for ; Thu, 31 Jan 2019 08:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hlMsZD/U2TytSDCS5MGz/UzZcdV9W2XD4KRgBZh12yI=; b=FuZtwezSztqX1ggF0TujtdTc5hkNuFVOc0zPl8xqqV7J0Z3KeIAL1HNCGxWfp2GSgV W1qw7MuVx62mMhfgWqZFGEohmc4qTt/PLOz0fhNFb5rddfsBvPE720krvQUXImwxYBlc roeiwSFCBXng7vd3ugDbbh2F81VRqArfjn1IudFmftKo7ot+vhlrR7OEqL/P/Zoh+UPY e4eFvttwi5qR8LdV+6mXWH914YR4wNx3KNkRMHZAg9uLdX+0U/t//Kx6pmXbDJRIQ6Pc mq5N3H10pl8LGzd6gikgRtq3qvdgVWf41uw3UsI2slft1R6UbiJPp2uk4979nj6b5lwT iXXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hlMsZD/U2TytSDCS5MGz/UzZcdV9W2XD4KRgBZh12yI=; b=d2zzLx1NoUuHQYcB+O6O0+gk53/vfEJuM9r+S5R7Gy4Q/cRrns+YTeleW3miBEvJC6 6GysR2xd4HwHqKfDhvXfYlKXxvy/95h04N3FOJ0NwwuynyoV8XkwH2pNq/w0nN/bEyiP +NU5M+eVa52PA5xxhF7iyJxfPrB/e60+Jh9VP0j9nHz8S4pILacDruB0rAtAbHgUFt54 K/yNijnTLHNGU1rJ/cbprWLLEsAE1RdGEE0OmV5ehg5r2zkmvdYfEwYtSPhuA+OfXyCn tAxN8QxcBW5S/y5EJT142ikiEmPG5hkOCGSgLIAzovdyXii1c3K+uvp4/DwbWATmgYJ4 /olA== X-Gm-Message-State: AJcUukd4KCke66c6LGHndRcJTBJCxyaOlKW1ZIhRNfVtWFSEel+FAKXX b0UBwYntZWqDccsDJaerfflzxutuFv0UkX50PuG63NUSs8M= X-Google-Smtp-Source: ALg8bN61j9DdetkFnl+IBb+lVDRMIJrsnc+3AQth5UPDcOYXaTFuLW6czdYbd3sqWp0WkCV8sWwd4axAsmcpcxIZLoc= X-Received: by 2002:a19:4287:: with SMTP id p129mr28569105lfa.135.1548952560871; Thu, 31 Jan 2019 08:36:00 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <1548943008.796.1.camel@gentoo.org> In-Reply-To: <1548943008.796.1.camel@gentoo.org> From: Alec Warner Date: Thu, 31 Jan 2019 11:35:49 -0500 Message-ID: Subject: Re: [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust To: gentoo-project Content-Type: multipart/alternative; boundary="0000000000002a43450580c39f72" X-Archives-Salt: 6e904421-15eb-4e4c-9e67-2b96ea0ed1b0 X-Archives-Hash: 428bba9037c8ab8fa91333adefe81cc6 --0000000000002a43450580c39f72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 31, 2019 at 8:56 AM Micha=C5=82 G=C3=B3rny = 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=C5=82 G=C3=B3rny > 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 > =3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 =E2=80=94 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 > uid [ultimate] Robert Someone > 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=3D/dev/urandom bs=3D1k count=3D1 | 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > n/a > > > References > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > .. [#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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > 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=C5=82 G=C3=B3rny > --0000000000002a43450580c39f72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 31, 2019 at 8:56 AM Micha= =C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
Hello,

Here's first draft of proposed GLEP for establishing a WoT inside
Gentoo.=C2=A0 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=C5=82 G=C3=B3rny <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
=3D=3D=3D=3D=3D=3D=3D=3D

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.=C2=A0 Advantages of a strong WoT are considered,
including its usefulness for sign-off real name verification.=C2=A0 Rules f= or
creating key signatures are established, and an example of signing
procedure is provided.


Motivation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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.=C2=A0 Appare= ntly,
there are still many Gentoo developers who do not have their
``@gento= o.org`` UID signed by another active developer.=C2=A0 Historically
there were also cases of developers signing others' UIDs without
actually verifying their identity.=C2=A0 [#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.=C2=A0 While this system reliably covers all Gentoo
developers, it has three major drawbacks:

1. It is entirely customary and therefore requires customized software
=C2=A0 =C2=A0to use.=C2=A0 In other words, it's of limited usefulness t= o people outside
=C2=A0 =C2=A0Gentoo or does not work out of the box there.
=

2. At least in the current form, it is entirely limited to Gentoo
=C2=A0 =C2=A0developers.=C2=A0 As such, it does not facilitate trust betwee= n them
=C2=A0 =C2=A0and the outer world.

3. It relies on a centralized server whose authenticity is in turn
=C2=A0 =C2=A0proved via PKI.=C2=A0 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.=C2=A0 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.=C2=A0 [#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 doe= s a WoT enable the project to do that it cannot do now?

-A
=C2=A0

Specification
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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
``@gento= o.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.=C2=A0 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
=C2=A0 prior to joining starting 2019-10-01,

- all existing developers will be required to have their key signed
=C2=A0 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
=C2=A0 =C2=A0verified.=C2=A0 Do not sign all identifiers unless you have pr= eviously
=C2=A0 =C2=A0verified all of them.

2. For the purpose of Gentoo sign-off usage, the key must have
=C2=A0 =C2=A0an identifier consisting of the real name of a natural person<= br> =C2=A0 =C2=A0(per GLEP 76) and the respective e-mail address to be used
=C2=A0 =C2=A0in ``Signed-off-by`` line.=C2=A0 In case of Gentoo developers,= this e-mail
=C2=A0 =C2=A0address has to be their ``@gentoo.org`` address.

=C2=A0 =C2=A0Other user identifiers do not need to strictly follow those ru= les,
=C2=A0 =C2=A0and may be skipped for the purpose of Gentoo key signing.=C2= =A0 However,
=C2=A0 =C2=A0you should follow the respective rules for verifying those kin= d
=C2=A0 =C2=A0of identifiers (e.g. XMPP UIDs should be signed after verifyin= g
=C2=A0 =C2=A0the working XEP-0373 or similar encryption, keybase.io UIDs should=
=C2=A0 =C2=A0follow appropriate keybase verification).=C2=A0 [#XEP-0373]_ =C2=A0 =C2=A0[#KEYBASE.IO]_

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

=C2=A0 =C2=A0a. Obtain a fingerprint of the person's primary key (for t= he purpose
=C2=A0 =C2=A0 =C2=A0 of verifying the authenticity of the key you're ab= out to sign).
=C2=A0 =C2=A0 =C2=A0 Usually, a printed strip containing ``gpg --list-key``= output
=C2=A0 =C2=A0 =C2=A0 is used for this purpose.

=C2=A0 =C2=A0b. Verify the person's real name (at least for the user id= entifier
=C2=A0 =C2=A0 =C2=A0 used for copyright purposes).=C2=A0 This is usually do= ne through
=C2=A0 =C2=A0 =C2=A0 verifying an identification document with photograph.= =C2=A0 It is
=C2=A0 =C2=A0 =C2=A0 a good idea to ask for the document type earlier, and = read on
=C2=A0 =C2=A0 =C2=A0 forgery protections used.

=C2=A0 =C2=A0 =C2=A0 In some cases, alternate methods of verifying the iden= tity may be
=C2=A0 =C2=A0 =C2=A0 used if they provide equivalent or better level of rel= iability.
=C2=A0 =C2=A0 =C2=A0 This can include e.g. use of national online identific= ation
=C2=A0 =C2=A0 =C2=A0 systems or bank transfers.

=C2=A0 =C2=A0c. Verify that the person has access to the corresponding e-ma= il
=C2=A0 =C2=A0 =C2=A0 address / web resource, e.g. by sending a block of ran= domly
=C2=A0 =C2=A0 =C2=A0 generated data and requesting sending it back, signed = using
=C2=A0 =C2=A0 =C2=A0 the respective key.

4. Once you signed a single user identifier of a particular person, you
=C2=A0 =C2=A0can sign new user identifiers by just verifying the e-mail add= ress
=C2=A0 =C2=A0without repeating identity verification (provided the new UIDs= share
=C2=A0 =C2=A0the same real name).

5. If you have reasons to believe that the particular person has lost
=C2=A0 =C2=A0access to the respective e-mail address (e.g. due to retiremen= t),
=C2=A0 =C2=A0that the real name is no longer valid or the user identifier b= ecame
=C2=A0 =C2=A0invalid for any other reason, you should revoke your previous<= br> =C2=A0 =C2=A0signature on it.


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

In order to improve key signing accessibility to developers, Gentoo will accept signatures made by members of partner communities.=C2=A0 The list of partner communities will be maintained in Gentoo Wiki [TODO].=C2=A0 New<= br> 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<= br> key.=C2=A0 In this section, we will only consider the process of signing Bob's key from Alice's perspective.=C2=A0 Usually, at the same time= Bob would
sign Alice's key =E2=80=94 with an equivalent process.

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

=C2=A0 =C2=A0 pub=C2=A0 =C2=A0rsa2048 2019-01-23 [SC] [expires: 2021-01-22]=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6CDE875E9CCF01D6E5691C9561FB7991B3D45B3C=
=C2=A0 =C2=A0 uid=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ultimate] Robert= Someone <bob@examp= le.com>
=C2=A0 =C2=A0 uid=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[ultimate] Robert= Someone <bob2@exa= mple.org>
=C2=A0 =C2=A0 sub=C2=A0 =C2=A0rsa2048 2019-01-23 [E] [expires: 2021-01-22]<= br>
Alice verifies the Bob's identity.=C2=A0 He gives her his ID card, stat= ing::

=C2=A0 =C2=A0 Given name: Robert
=C2=A0 =C2=A0 Family name: Someone

Ideally, Alice would have known what kind of document to expected
and would have read up on verifying it.=C2=A0 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::

=C2=A0 =C2=A0 dd if=3D/dev/urandom bs=3D1k count=3D1 | base64

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

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


Rationale
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Milestones
----------

The transitional period is provided so that developers currently missing user signatures are given time to obtain them.=C2=A0 Initially, the period<= br> 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.=C2=A0 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.=C2=A0 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.=C2=A0 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.=C2=A0 In context of those, it require= s
at least a single identifier that actually has a real name for GLEP 67
purposes.=C2=A0 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.=C2=A0 Real name and e-mail verification is used to confirm
the authenticity of each user identifier being signed.=C2=A0 Use of random<= br> 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.=C2=A0 This is helpful=
e.g. when a person obtains new e-mail addresses, and wishes to get them
signed.=C2=A0 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.=C2=A0 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).=C2=A0 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.=C2=A0 They also explicitly note
the necessity of verifying identity.=C2=A0 In case it's really impossib= le to
meet another developer, the Front Desk (equivalent of Recruiters) may
offer an alternative way of identification.=C2=A0 [#DEBIAN-IDENTIFICATION]_=

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

Backwards Compatibility
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Gentoo does not use any particular web of trust policy at the moment.
Not all of existing signatures conform to the new policy.=C2=A0 Therefore,<= br> 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
n/a


References
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

.. [#WOT-STATS] WoT Node Stats
=C2=A0 =C2=A0(https://qa-reports.gentoo.org/outpu= t/wot-stats.html)

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

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

.. [#KEY= BASE.IO] Keybase
=C2=A0 =C2=A0(https://keybase.io/)

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

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


Copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D
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=C5=82 G=C3=B3rny
--0000000000002a43450580c39f72--