On Thu, Jan 31, 2019 at 8:56 AM 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. > > --- > > --- > GLEP: 9999 > Title: Gentoo OpenPGP web of trust > Author: Michał Górny > 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 > 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=/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 >