GLEP 80: Identity verification via OpenPGP WoT

Purpose and scope

This specification does not enforce identity verification anywhere. Instead, it aims to provide clear rules for whenever developers establish such a process is necessary. Identity verification may be enforced in specific groups of developers separately, via internal project policies or Council-approved policies.

If a identity is verified according to this specification, this fact should be recorded via signing UIDs matching the verified data on the person's OpenPGP key. Such signature cryptographically confirms that the signer has verified that the specific signee's UID provides legitimate real name and e-mail address of the key owner. Furthermore, it is recommended that the signer includes the URL of this GLEP as the certification policy URL (--cert-policy-url in gpg(1)), and appropriately indicates certification level (see --default-cert-level in gpg(1)).

The certification level of signatures following this specification must be either 2 or 3, depending on how minutely the signer verified signee's identification documents.

Identity verification

GnuPG command line (informational)

In order to create a signature following this specification, the following command-line arguments can be used:

gpg --cert-policy-url 'https://www.gentoo.org/glep/glep-0080.rst' \
    --ask-cert-level --cert-digest-algo SHA512 \
    --edit-key <key-fingerprint>

Alternatively, if those options should apply to all certifications made, they can be included in the configuration file ~/.gnupg/gpg.conf:

cert-policy-url https://www.gentoo.org/glep/glep-0080.rst
ask-cert-level
cert-digest-algo SHA512

cert-policy-url specifies the policy to which the certification complies (as recommended above). ask-cert-level requests GnuPG to query certification level interactively when signing every key. cert-digest-algo enables stronger SHA-2 512-bit digests on certifications.

Non-obligatory nature

The previous WoT proposal made signatures obligatory. This has met with resistance of developers, including claims that there are individuals within Gentoo who are unable to get their key signed using any of the proposed methods and outright rejection of real name verification. [2]

Therefore, this proposal avoids making keysigning obligatory for everyone. However, it does aim to provide official rule set for keysigning that can be used by developers at their discretion, or whenever there is a valid need of verifying contributor's identity.

The GLEP also makes provisions for enforcing identity verification separately, as a matter of policy. While it could propose establishing such a policy for particular projects such as Infra, it makes little sense to maintain a list of such projects in a GLEP, and update it whenever it changes. Instead, individual projects can enforce name verification on their members, or Council can enforce wider policies if there is an agreement on them.

Face-to-face verification rules

The verification rules follow common keysigning practices. Notably, they are based on assumption that a single signature confirms the combination of three elements: the signee's primary key, real name and an e-mail address.

Verifying the primary key fingerprint is important to ensure that the authentic key belonging to the signee is being used. Otherwise, a malicious third party could create a key with matching UID and signer could sign it instead of the authentic key.

Verifying the real name is the specific purpose of this GLEP, as well as a standard practice for OpenPGP web of trust. The name should be verified against documents that are expectedly hard to forge, and that include photograph that could be used to verify the owner. Since photograph verification is non-trivial and in some cases documents contain outdated photos, it is supplemented with signature verification whenever possible. In any case, this part is considered best effort.

Verifying the e-mail address is necessary since OpenPGP does not provide any proof of address ownership, and arbitrary user identifiers can be added to a key. Unique data needs to be used in order to verify each address separately. The data is encrypted to additionally confirm that the e-mail address' owner actually has access to the key, and to avoid accidental mistakes.

Traditionally, it is considered sufficient to export a signature for each e-mail address, and send it. Then, the signee can decrypt it, import and publish the update to his key afterwards without the necessity of any further action from the signer. Doing this manually is non-trivial; the caff tool can help. [3]

Alternatively, a simple encrypted e-mail exchange with random data can be used instead. Afterwards, the signer signs all confirmed UIDs and publishes the signature. This method does not require special tooling and has the additional advantage of verifying that the signee can send mail from claimed address.

Allowing webcam identification

There are conflicting opinions as to whether remote identity verification is valid. However, this method can prove helpful whenever the signee does not live near any developer.

The use of live, high-resolution stream aims to both reduce the risk of forgery and copying signee's identification documents. The ability to move freely is also necessary to provide at least partial verification of counter-forgery measures.

Allowing government identification services

Finally, whenever direct verification is inconvenient, it could be acceptable to rely on government officials and institutions that are expected to verify the identity of citizens. The most common case of this are public notaries who can provide appropriate proofs of identity for a fee.

Besides those, if the signer and signee live in the same country, additional national verification mechanisms may be used as long as special care is taken to perform an authenticated exchange.

In some cases, randomly-generated data exchange via wire transfer may be considered sufficient, provided that the signee's bank is known to verify identity of its customers.