[gentoo-project] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[gentoo-project] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[Michał Górny]

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

Hi,

Here's a revival of WoT pre-GLEP.  I've followed the earlier
suggestions, and rewritten it from scratch with a different perspective.

Unlike the previous proposal, this one is focused entirely on providing
a distributed identity verification method, with OpenPGP key signatures
being used as a technical means for storing the verification result. 
The construction of WoT is merely a side effect.

The GLEP itself does not enforce signing in any circumstances.  It could
be useful e.g. when developers have reasons not to believe in proxy-
maintainers' identities, and need some proof.  I also recommend
enforcing it e.g. inside Infra project but GLEP leaves that for
a separate policy.

The text below.

---
GLEP: 9999
Title: Identity verification via OpenPGP WoT
Author: Michał Górny <mgorny@gentoo.org>
Type: Standards Track
Status: Draft
Version: 1
Created: 2019-03-04
Last-Modified: 2019-03-04
Post-History: 2019-03-04
Content-Type: text/x-rst
Requires:
Replaces:
---

Abstract
========
This GLEP proposes establishing a non-obligatory, distributed identity
verification procedure that is compatible with OpenPGP web of trust.  It
could be used whenever an explicit need for verifying the real name
occurs, enforced on groups of developers with elevated privileges
via a separate policy or serve as guidelines for building web of trust.
Three methods of verifying the identity are proposed: face-to-face,
via webcam or via government-controlled identification services.


Motivation
==========
GLEP 76 (Copyright Policy) specifies that all commits made to Gentoo
repositories must include a sign-off with a person's real name.
However, it does not specify any particular method of verifying it.
It is a standing policy that it is sufficient for contributor to
acknowledge the legitimacy of the provided name.  [#GLEP76]_

At the same time, developers are asked not to accept contributions
if they have justified concerns as to the authenticity of the name
provided.  In particular, this could happen if the developer happens
to know the contributor personally, the contributor indicated that he
is using a pseudonym or arbitrarily changed his name under the policy.
In this case, we lack a clear policy allowing the contributor
to reattain trust.

Furthermore, enforcing higher standards for identity verification may
make sense for groups having elevated privileges or specific legal
responsibility, e.g. the Infrastructure team or Trustees.

If a centralized identity verification model was to be introduced
in Gentoo, it would probably be necessary to perform most
of the verifications remotely.  This would require transferring
sensitive personal data to a single entity which is undesirable.

On the other hand, a distributed identity verification model is readily
provided by OpenPGP Web of Trust.  In this case, verification can be
performed between individual pairs of developers, reducing the amount of
sensitive information at the disposal of a single entity and increasing
the chances of performing the verification face-to-face.


Specification
=============
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 GnuPG),
and appropriately indicates certification level (see
``--default-cert-level`` in GnuPG).


Identity verification
---------------------
Face-to-face verification
~~~~~~~~~~~~~~~~~~~~~~~~~
The recommended procedure for identity verification is for the signer
to meet signee face-to-face.  The signer must:

1. Obtain a hardcopy of signee's OpenPGP key fingerprint.  The signer
   must afterwards use the fingerprint to verify the authenticity
   of the key being used.

2. Verify the signee's identity using a government-issued identification
   document with a photograph.  The verification must include,
   to the best of signer's abilities:

   a. Verifying that the counter-forgery features of the verified
      document are present and are correct.

   b. Verifying that the signee's face resembles the photograph
      on the document.

   c. Verifying that the signee is able to issue a signature similar
      to the one on the document (if present).

3. Verify the signee's e-mail address(es), through sending an e-mail
   encrypted using signee's OpenPGP key, containing either randomly
   generated data, or an exported signature for the UID in question.
   Each mail sent must contain unique data.

Only once all three factors are positively verified may the particular
UID be signed according to this policy.


Remote webcam verification
~~~~~~~~~~~~~~~~~~~~~~~~~~
Alternatively to face-to-face verification, it is acceptable to perform
the verification using high-resolution real-time video stream.  In this
case, the signee should perform all the actions necessary for the signer
to be able to verify the identity document in front of the camera.


Verification via government identity services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Finally, it is acceptable to use one of the identity proof forms that
are considered legally meaningful in a particular country, and guarantee
the signee's identity has been verified by an official.  This could
include e.g.:

- public notaries,

- government identity services (provided that the signer is able to
  obtain a cryptographically secured proof of identity),

- bank wire transfers.


Rationale
=========
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.
[#WOT-JAN2019]_

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.  [#CAFF]_

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.


Backwards Compatibility
=======================
The policy is non-obligatory, and therefore does not affect existing
developers.

Existing developer signatures may be incompatible with the policy.
In order to make policy conformance clear, the GLEP recommends including
appropriate policy URL in signatures.


Reference Implementation
========================
n/a


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

.. [#WOT-JAN2019] [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust
   (https://archives.gentoo.org/gentoo-project/message/d05ae93cac6fbac0eea07fc597519382)

.. [#CAFF] caff - Debian Wiki
   (https://wiki.debian.org/caff)


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] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[Rich Freeman]

On Mon, Mar 4, 2019 at 2:06 PM Michał Górny <mgorny@gentoo.org> wrote:

> Furthermore,
> it is recommended that the signer includes the URL of this GLEP
> as the certification policy URL (``--cert-policy-url`` in GnuPG),
> and appropriately indicates certification level (see
> ``--default-cert-level`` in GnuPG).

Rather than say "appropriately" why not explicitly indicate which
certification level to use?  Otherwise the distinction between 2/3 is
going to become a point of debate.  If you're going to standardize the
URL it seems like standardizing the level makes sense (IMO specifying
the URL for disambiguation is a great idea).

>
> 1. Obtain a hardcopy of signee's OpenPGP key fingerprint.  The signer
>    must afterwards use the fingerprint to verify the authenticity
>    of the key being used.

This seems needlessly specific.  How about just requiring that they
verify the fingerprint of the key to be signed with the person signing
it.  That could mean being handed a hardcopy, but it it could just
mean being shown the fingerprint and transcribing it, or comparing it
on-screen, etc.  Obviously it needs to be communicated via a
reasonably tamper-proof mechanism.

This just seems to necessitate printing out keys when other methods
might be just as secure.  Maybe focus more on the what than the how.

-- 
Rich

Re: [gentoo-project] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[Michał Górny]

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

On Mon, 2019-03-04 at 14:18 -0500, Rich Freeman wrote:
> On Mon, Mar 4, 2019 at 2:06 PM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Furthermore,
> > it is recommended that the signer includes the URL of this GLEP
> > as the certification policy URL (``--cert-policy-url`` in GnuPG),
> > and appropriately indicates certification level (see
> > ``--default-cert-level`` in GnuPG).
> 
> Rather than say "appropriately" why not explicitly indicate which
> certification level to use?  Otherwise the distinction between 2/3 is
> going to become a point of debate.  If you're going to standardize the
> URL it seems like standardizing the level makes sense (IMO specifying
> the URL for disambiguation is a great idea).

Well, I believe both 2 and 3 can be valid, depending on how minutely
you've verified the document.  I'd say you'd say 3 if you really
carefully ensured all three points (including multiple anti-counterfeit
measures); 2 if you just looked if the document looks reasonable but
failed to prepare.

> > 1. Obtain a hardcopy of signee's OpenPGP key fingerprint.  The signer
> >    must afterwards use the fingerprint to verify the authenticity
> >    of the key being used.
> 
> This seems needlessly specific.  How about just requiring that they
> verify the fingerprint of the key to be signed with the person signing
> it.  That could mean being handed a hardcopy, but it it could just
> mean being shown the fingerprint and transcribing it, or comparing it
> on-screen, etc.  Obviously it needs to be communicated via a
> reasonably tamper-proof mechanism.
> 
> This just seems to necessitate printing out keys when other methods
> might be just as secure.  Maybe focus more on the what than the how.

Sorry, non-native English speaker here.  I thought the intent is clear
from the sentence, and people are going to be able to figure out that
the purpose is to have tamper-proof value here.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[Rich Freeman]

On Mon, Mar 4, 2019 at 2:57 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Mon, 2019-03-04 at 14:18 -0500, Rich Freeman wrote:
> > On Mon, Mar 4, 2019 at 2:06 PM Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > Furthermore,
> > > it is recommended that the signer includes the URL of this GLEP
> > > as the certification policy URL (``--cert-policy-url`` in GnuPG),
> > > and appropriately indicates certification level (see
> > > ``--default-cert-level`` in GnuPG).
> >
> > Rather than say "appropriately" why not explicitly indicate which
> > certification level to use?  Otherwise the distinction between 2/3 is
> > going to become a point of debate.  If you're going to standardize the
> > URL it seems like standardizing the level makes sense (IMO specifying
> > the URL for disambiguation is a great idea).
>
> Well, I believe both 2 and 3 can be valid, depending on how minutely
> you've verified the document.  I'd say you'd say 3 if you really
> carefully ensured all three points (including multiple anti-counterfeit
> measures); 2 if you just looked if the document looks reasonable but
> failed to prepare.

You said "The verification must include, to the best of signer's
abilities" which implies that #2 isn't really allowed in this case.

If we want to leave it up to individual discretion I guess it is fine.
Just expect variation.  What counts as #3 for one person might be
different from another's judgment.  The gpg docs say as much as well.
If you do want some standard applied then maybe be explicit.

> > > 1. Obtain a hardcopy of signee's OpenPGP key fingerprint.  The signer
> > >    must afterwards use the fingerprint to verify the authenticity
> > >    of the key being used.
> >
> > This seems needlessly specific.  How about just requiring that they
> > verify the fingerprint of the key to be signed with the person signing
> > it.  That could mean being handed a hardcopy, but it it could just
> > mean being shown the fingerprint and transcribing it, or comparing it
> > on-screen, etc.  Obviously it needs to be communicated via a
> > reasonably tamper-proof mechanism.
> >
> > This just seems to necessitate printing out keys when other methods
> > might be just as secure.  Maybe focus more on the what than the how.
>
> Sorry, non-native English speaker here.  I thought the intent is clear
> from the sentence, and people are going to be able to figure out that
> the purpose is to have tamper-proof value here.

The word "hardcopy" generally means something printed on paper.  A
non-paper-based process would not involve a "hardcopy" of anything.

If the intent was to just convey the need to verify the fingerprint,
then maybe reword to:

1. Obtain the signee's OpenPGP key fingerprint.  The signer
    must use the fingerprint to verify the authenticity
    of the key being used.

I removed "hardcopy" and "afterwards."  We don't care what media is
used to transfer the fingerprint if it is secure (this is in-person,
so I think we can leave that detail out).  We really don't care the
order the various steps happen in either - if they want to check the
fingerprint before looking at the photo ID/etc that is fine.

-- 
Rich

Re: [gentoo-project] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[Michał Górny]

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

On Mon, 2019-03-04 at 15:29 -0500, Rich Freeman wrote:
> On Mon, Mar 4, 2019 at 2:57 PM Michał Górny <mgorny@gentoo.org> wrote:
> > On Mon, 2019-03-04 at 14:18 -0500, Rich Freeman wrote:
> > > On Mon, Mar 4, 2019 at 2:06 PM Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > Furthermore,
> > > > it is recommended that the signer includes the URL of this GLEP
> > > > as the certification policy URL (``--cert-policy-url`` in GnuPG),
> > > > and appropriately indicates certification level (see
> > > > ``--default-cert-level`` in GnuPG).
> > > 
> > > Rather than say "appropriately" why not explicitly indicate which
> > > certification level to use?  Otherwise the distinction between 2/3 is
> > > going to become a point of debate.  If you're going to standardize the
> > > URL it seems like standardizing the level makes sense (IMO specifying
> > > the URL for disambiguation is a great idea).
> > 
> > Well, I believe both 2 and 3 can be valid, depending on how minutely
> > you've verified the document.  I'd say you'd say 3 if you really
> > carefully ensured all three points (including multiple anti-counterfeit
> > measures); 2 if you just looked if the document looks reasonable but
> > failed to prepare.
> 
> You said "The verification must include, to the best of signer's
> abilities" which implies that #2 isn't really allowed in this case.
> 
> If we want to leave it up to individual discretion I guess it is fine.
> Just expect variation.  What counts as #3 for one person might be
> different from another's judgment.  The gpg docs say as much as well.
> If you do want some standard applied then maybe be explicit.
> 
> > > > 1. Obtain a hardcopy of signee's OpenPGP key fingerprint.  The signer
> > > >    must afterwards use the fingerprint to verify the authenticity
> > > >    of the key being used.
> > > 
> > > This seems needlessly specific.  How about just requiring that they
> > > verify the fingerprint of the key to be signed with the person signing
> > > it.  That could mean being handed a hardcopy, but it it could just
> > > mean being shown the fingerprint and transcribing it, or comparing it
> > > on-screen, etc.  Obviously it needs to be communicated via a
> > > reasonably tamper-proof mechanism.
> > > 
> > > This just seems to necessitate printing out keys when other methods
> > > might be just as secure.  Maybe focus more on the what than the how.
> > 
> > Sorry, non-native English speaker here.  I thought the intent is clear
> > from the sentence, and people are going to be able to figure out that
> > the purpose is to have tamper-proof value here.
> 
> The word "hardcopy" generally means something printed on paper.  A
> non-paper-based process would not involve a "hardcopy" of anything.
> 
> If the intent was to just convey the need to verify the fingerprint,
> then maybe reword to:
> 
> 1. Obtain the signee's OpenPGP key fingerprint.  The signer
>     must use the fingerprint to verify the authenticity
>     of the key being used.
> 
> I removed "hardcopy" and "afterwards."  We don't care what media is
> used to transfer the fingerprint if it is secure (this is in-person,
> so I think we can leave that detail out).  We really don't care the
> order the various steps happen in either - if they want to check the
> fingerprint before looking at the photo ID/etc that is fine.

Actually, we *do* care that the media is secure.  You need to make sure
that you actually get the key from the person you've just met. 
Otherwise, someone would soon enough use e-mail or IRC, or any other
channel, making it trivial for a forged key to be substituted.

Anyway, I've attempted to rewrite it and I'll resend it in a few
minutes.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] [RFC pre-GLEP r1] Identity verification via OpenPGP WoT

[Michał Górny]

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

Hi,

Here's -r1.  Changes:

- Included more explanation of cert levels.

- Allowed more secure forms of key verification than fingerprint (after
all, fingerprint is SHA-1 of key material).

- Allowed any secure channel for key exchange, with paper staying
the recommendation.

- Added a section with command-line options matching the spec.

---
GLEP: 9999
Title: Identity verification via OpenPGP WoT
Author: Michał Górny <mgorny@gentoo.org>
Type: Standards Track
Status: Draft
Version: 1
Created: 2019-03-04
Last-Modified: 2019-03-05
Post-History: 2019-03-04
Content-Type: text/x-rst
Requires:
Replaces:
---

Abstract
========
This GLEP proposes establishing a non-obligatory, distributed identity
verification procedure that is compatible with OpenPGP web of trust.  It
could be used whenever an explicit need for verifying the real name
occurs, enforced on groups of developers with elevated privileges
via a separate policy or serve as guidelines for building web of trust.
Three methods of verifying the identity are proposed: face-to-face,
via webcam or via government-controlled identification services.


Motivation
==========
GLEP 76 (Copyright Policy) specifies that all commits made to Gentoo
repositories must include a sign-off with a person's real name.
However, it does not specify any particular method of verifying it.
It is a standing policy that it is sufficient for contributor to
acknowledge the legitimacy of the provided name.  [#GLEP76]_

At the same time, developers are asked not to accept contributions
if they have justified concerns as to the authenticity of the name
provided.  In particular, this could happen if the developer happens
to know the contributor personally, the contributor indicated that he
is using a pseudonym or arbitrarily changed his name under the policy.
In this case, we lack a clear policy allowing the contributor
to reattain trust.

Furthermore, enforcing higher standards for identity verification may
make sense for groups having elevated privileges or specific legal
responsibility, e.g. the Infrastructure team or Trustees.

If a centralized identity verification model was to be introduced
in Gentoo, it would probably be necessary to perform most
of the verifications remotely.  This would require transferring
sensitive personal data to a single entity which is undesirable.

On the other hand, a distributed identity verification model is readily
provided by OpenPGP Web of Trust.  In this case, verification can be
performed between individual pairs of developers, reducing the amount of
sensitive information at the disposal of a single entity and increasing
the chances of performing the verification face-to-face.


Specification
=============
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
---------------------
Face-to-face verification
~~~~~~~~~~~~~~~~~~~~~~~~~
The recommended procedure for identity verification is for the signer
to meet signee face-to-face.  The signer must:

1. Obtain the signee's OpenPGP key fingerprint, the complete public key
   data or a stronger digest of it over a tamper-resistant channel
   (preferably on paper).  The signer must reliably compare this data to
   verify the authenticity of the key being signed.

2. Verify the signee's identity using a government-issued identification
   document with a photograph.  The verification must include,
   to the best of signer's abilities:

   a. Verifying that the counter-forgery features of the verified
      document are present and are correct.

   b. Verifying that the signee's face resembles the photograph
      on the document.

   c. Verifying that the signee is able to issue a signature similar
      to the one on the document (if present).

3. Verify the signee's e-mail address(es), through sending an e-mail
   encrypted using signee's OpenPGP key, containing either randomly
   generated data, or an exported signature for the UID in question.
   Each mail sent must contain unique data.

Only once all three factors are positively verified may the particular
UID be signed according to this policy.


Remote webcam verification
~~~~~~~~~~~~~~~~~~~~~~~~~~
Alternatively to face-to-face verification, it is acceptable to perform
the verification using high-resolution real-time video stream.  In this
case, the signee should perform all the actions necessary for the signer
to be able to verify the identity document in front of the camera.


Verification via government identity services
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Finally, it is acceptable to use one of the identity proof forms that
are considered legally meaningful in a particular country, and guarantee
the signee's identity has been verified by an official.  This could
include e.g.:

- public notaries,

- government identity services (provided that the signer is able to
  obtain a cryptographically secured proof of identity),

- bank wire transfers.


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-9999.rst' \
        --ask-cert-level --cert-digest-algo SHA512 \
        --edit-key <key-fingerprint>

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

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

.. TODO: update URL when number is assigned

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


Rationale
=========
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.
[#WOT-JAN2019]_

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.  [#CAFF]_

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.


Backwards Compatibility
=======================
The policy is non-obligatory, and therefore does not affect existing
developers.

Existing developer signatures may be incompatible with the policy.
In order to make policy conformance clear, the GLEP recommends including
appropriate policy URL in signatures.


Reference Implementation
========================
n/a


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

.. [#WOT-JAN2019] [gentoo-project] pre-GLEP: Gentoo OpenPGP web of trust
   (https://archives.gentoo.org/gentoo-project/message/d05ae93cac6fbac0eea07fc597519382)

.. [#CAFF] caff - Debian Wiki
   (https://wiki.debian.org/caff)


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] [RFC pre-GLEP] Identity verification via OpenPGP WoT

[Kristian Fiskerstrand]

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

On 3/4/19 8:06 PM, Michał Górny wrote:
> Hi,
> 
> Here's a revival of WoT pre-GLEP.  I've followed the earlier
> suggestions, and rewritten it from scratch with a different perspective.

I promised to come back on the ML with some feedback on this matter, so
here we go.

Since this is a non-mandatory recommendation I question whether it makes
sense as a GLEP to begin with, as it can rather be maintained in some
other location by a project, but leaving that aside for now there are
some structural issues with the proposed GLEP.

The GLEP should outline the governance model for how a policy is set,
whom update it and what the goals of such a policy is. One of the more
important points for the GLEP would be how to use it, basically a
permanent URI to use for a policy URI in accordance with rfc4880 section
5.2.3.20. This URI needs to allow for versioning to allow for updating
in a reasonable manner. If the policy is the GLEP itself, an update will
normally be another GLEP so there is no consistency in the URIs nor an
easy blackline of the changes between policies. The first policy can of
course be attached to a GLEP, but the policy itself belongs in a
revision controlled repository to allow for changes, and updating it can
be delegated to a project set up for the purpose, possibly with with an
explicit, or likely an implisit, involvement with other projects such as
Security.

As for the policy itself; Such a policy very similar to requirements for
Certification Practice Statement (CPS) for certificate authorities as
outlined in the CAB Forum Baseline Requirements (
https://www.cabforum.org ). As an example one can look at letsencrypt's
CPS at https://letsencrypt.org/documents/isrg-cps-v2.3/.

The specific policy for instance does not specify the significance of
the various signing levels found in rfc4880 section 5.2.1. One possible
interprentation would for instance be that a 0x13 signature can be used
for a signature where the developers have met face to face, but a
digital verification is allowed to use a 0x12 signature. Either could be
allowed to use the more generic 0x10 signature type.

But the initial reaction is that this policy itself does not belong as a
GLEP, which should be focused on the structure, and the policy itself is
not ready, but a project can work on this if a project is created and
the URI is determined and linked to a tag in a git repository or the
like. A proposed alternative is
https://www.gentoo.org/openpgp-signing-policy/v1/ where v1 is mapping to
a git tag for an HTTP 302 c.f rfc2616


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