Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11956 > unrolled thread

Keysigning in times of COVID-19

Back to article view | Back to linux.debian.project

Contents

  Keysigning in times of COVID-19 Enrico Zini <enrico@enricozini.org> - 2020-08-06 18:10 +0200
    Re: Keysigning in times of COVID-19 Roberto C. Sánchez <roberto@debian.org> - 2020-08-06 18:50 +0200
      Re: Keysigning in times of COVID-19 Federico Ceratto <federico.ceratto@gmail.com> - 2020-08-17 20:30 +0200
        Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-17 21:10 +0200
          Re: Keysigning in times of COVID-19 Wouter Verhelst <wouter@debian.org> - 2020-08-19 16:20 +0200
            Re: Keysigning in times of COVID-19 rhkramer@gmail.com - 2020-08-19 18:10 +0200
              Re: Keysigning in times of COVID-19 Philip Hands <phil@hands.com> - 2020-08-20 10:20 +0200
                Re: Keysigning in times of COVID-19 Andrey Rahmatullin <wrar@debian.org> - 2020-08-20 10:50 +0200
                Re: Keysigning in times of COVID-19 Ansgar <ansgar@debian.org> - 2020-08-20 10:50 +0200
                Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-20 12:20 +0200
                  Re: Keysigning in times of COVID-19 Russ Allbery <rra@debian.org> - 2020-08-20 19:30 +0200
                Re: Keysigning in times of COVID-19 Florian Weimer <fw@deneb.enyo.de> - 2020-08-23 23:10 +0200
    Re: Keysigning in times of COVID-19 Felix Lechner <felix.lechner@lease-up.com> - 2020-08-06 19:10 +0200
    Re: Keysigning in times of COVID-19 Johannes Schauer <josch@debian.org> - 2020-08-06 19:30 +0200
      Re: Keysigning in times of COVID-19 Holger Levsen <holger@layer-acht.org> - 2020-08-07 11:40 +0200
    Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-06 19:40 +0200
    Re: Keysigning in times of COVID-19 Christian Kastner <ckk@debian.org> - 2020-08-06 23:40 +0200
    Re: Keysigning in times of COVID-19 Héctor Orón Martínez <hector.oron@gmail.com> - 2020-08-07 01:30 +0200
    Re: Keysigning in times of COVID-19 Alexandre Viau <aviau@debian.org> - 2020-08-07 09:30 +0200
      Re: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-07 12:00 +0200
    Re: Keysigning in times of COVID-19 Didier 'OdyX' Raboud <odyx@debian.org> - 2020-08-07 12:00 +0200
    Re: Keysigning in times of COVID-19 Alberto Garcia <berto@igalia.com> - 2020-08-07 12:10 +0200
    Re: Keysigning in times of COVID-19 Adrian Bunk <bunk@debian.org> - 2020-08-07 16:10 +0200
      Re: Keysigning in times of COVID-19 Ulrike Uhlig <ulrike@debian.org> - 2020-08-07 18:50 +0200
      Re: Keysigning in times of COVID-19 Gunnar Wolf <gwolf@debian.org> - 2020-08-09 07:50 +0200
        Re: Keysigning in times of COVID-19 Adrian Bunk <bunk@debian.org> - 2020-08-10 20:00 +0200
    Re: Keysigning in times of COVID-19 Gunnar Wolf <gwolf@debian.org> - 2020-08-09 07:40 +0200
    Re: Keysigning in times of COVID-19 Jonathan McDowell <noodles@earth.li> - 2020-08-12 10:10 +0200
      Re: Expressing regrets for how I handled the transition to Identity Verification  in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-12 14:30 +0200
    Re: Potential Summary: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-12 14:10 +0200
      Re: Potential Summary: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-12 14:30 +0200
      Re: Potential Summary: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-13 08:20 +0200
        Re: Potential Summary: Keysigning in times of COVID-19 Adam Borowski <kilobyte@angband.pl> - 2020-08-13 19:30 +0200
          Re: Potential Summary: Keysigning in times of COVID-19 Pirate Praveen <praveen@onenetbeyond.org> - 2020-08-13 20:20 +0200
            Re: Potential Summary: Keysigning in times of COVID-19 Adam Borowski <kilobyte@angband.pl> - 2020-08-13 21:10 +0200
              Re: Potential Summary: Keysigning in times of COVID-19 Steve McIntyre <steve@einval.com> - 2020-08-13 23:10 +0200
                Re: Potential Summary: Keysigning in times of COVID-19 Adrian Bunk <bunk@debian.org> - 2020-08-14 18:50 +0200
                  Re: Potential Summary: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-14 23:00 +0200
                    Re: Potential Summary: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-14 23:10 +0200
                      Re: Potential Summary: Keysigning in times of COVID-19 Jonas Smedegaard <dr@jones.dk> - 2020-08-15 00:30 +0200
              Re: Potential Summary: Keysigning in times of COVID-19 Christian Kastner <ckk@debian.org> - 2020-08-13 23:10 +0200
                Re: Potential Summary: Keysigning in times of COVID-19 Adam Borowski <kilobyte@angband.pl> - 2020-08-14 00:40 +0200
          Re: Potential Summary: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-13 21:40 +0200
    Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-12 17:30 +0200
      Re: Keysigning in times of COVID-19 Paul Wise <pabs@debian.org> - 2020-08-13 08:20 +0200
        Re: Keysigning in times of COVID-19 Sam Hartman <hartmans@debian.org> - 2020-08-13 14:00 +0200
          Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-13 14:20 +0200
            Re: Keysigning in times of COVID-19 Guilhem Moulin <guilhem@debian.org> - 2020-08-13 14:50 +0200
              Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-13 16:50 +0200
                Re: Keysigning in times of COVID-19 Ángel <debian-project@debian.16bits.net> - 2020-08-14 04:00 +0200
                  Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-16 15:40 +0200
        Re: Keysigning in times of COVID-19 rhkramer@gmail.com - 2020-08-13 14:00 +0200
        Re: Keysigning in times of COVID-19 Pierre-Elliott Bécue <peb@debian.org> - 2020-08-13 14:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#11967

[Multipart message — attachments visible in raw view] — view raw

Le jeudi, 6 août 2020, 17.54:21 h CEST Enrico Zini a écrit :
> What do you think could be alternative key signing policies, that would
> be acceptable to you, that would not require traveling and meeting face
> to face?

Several others have eloquently described key signing policies close to mine, 
but I'll phrase mine here nevertheless.

Since the rumbles of "someone showed up with either a fake passport, or a 
passport from a not-universally-recognised coutry at a keysigning party", I 
became quite dubious about key signing parties: I am not trained, skilled or 
equipped to validate identity papers from any country, and would probably be 
fooled by a reasonable copy of a swiss identity card. It's of much more value 
to me to get random non-official papers (a driving license, a business card, a 
library member card, etc) that are coherent between themselves: that at least 
shows an "identity continuity", that I would expect to be also coherent with 
the identity on the key.

The line I try to stick with is "crowd knowledge": is this person I'm about to 
sign the key of "known" as the name they claim to carry? Does their key "name" 
correspond to one or some of the names they go by? In recent times (during 
which physical encounters were still a possibility), I have actually asked 
someone else around "can you tell me the name of this person I'm about to sign 
the key of?" I have also often had a very small chit-chat: "what do you do in 
Debian / free software?", "what brought you here?". It's not an interview per 
se, but answers still matter.

Pseudonyms are totally OK for me, as long as the pseudos are in use: person A 
has an "official" "John Doe" identity, but they usually go as "Eric"; sign 
their emails with Eric, and get called by (free software) friends "Eric". In 
absence of any identity paper, provided they answer as "Eric", are known as 
"Eric", I would clearly sign their key even without any trace of John Doe 
anywhere. I don't need to know their "official" name is "John Doe", actually.

My own key is a good case for thought: my "Oriole" identity (and email) got 
signed a lot by DDs (but not always) despite me not mentionning this pseudonym 
of mine much, or at all: I am not known, nor would be called "Oriole" in 
Debian (but would likely respond to that name), but it's still an identity I 
carry in some circles.

Thanks for sparkling that conversation Enrico, it's very interesting!

Cheers,
    OdyX, or is it Didier, or Oriole ?

[toc] | [prev] | [next] | [standalone]

#11969

On Thu, Aug 06, 2020 at 05:54:21PM +0200, Enrico Zini wrote:
> What do you think could be alternative key signing policies, that
> would be acceptable to you, that would not require traveling and
> meeting face to face?

I don't have specific suggestions for a key signing policy but I wrote
this some years ago when this topic came up and I think it's worth
remembering it:

The main purpose of signing someone's key is not to show that you know
that person, but to confirm that the key belongs to the person whose
name and e-mail address appear on it. That means that your communicate
with that person in a trusted way, not that you necessarily have to
trust what they do. And it doesn't even matter if the name written on
the key is the same that appears on the passport or ID card (people
can use a different name for a variety of reasons).

I did not become a Debian developer because I had several signatures
on my key but because I spent some time contributing to Debian and
packaging software, then I got to know other developers, they learned
to trust me, they considered that the work that I had done was good
enough, then advocated me, then I went into a lengthy interview
with several technical and philosophical questions, and only after
that I became a member. The PGP key was just a tool to make the
communication more reliable, and as a matter of fact many of my
interactions with other people from Debian (IRC, bug tracker) is not
done in any cryptographically secure way.

Berto

[toc] | [prev] | [next] | [standalone]

#11970

On Thu, Aug 06, 2020 at 05:54:21PM +0200, Enrico Zini wrote:
>...
> Technically, every DD has their own policies for signing keys,
>...
> It might require to check a government issued photo ID, or it might not.

I thought this was the sole fixed requirement for keysigning.

>...
> As DAM, I would have a problem if someone automatically signed the keys
> of every stanger who asked them nicely in an email. At the same time, I
> am open to the idea of policies that do not require meeting people in
> person.
>...

Why are you requiring key signing at all when it has no defined semantics?

Many DDs check only the government issued photo ID for signing a key and 
this is also how keysigning parties work, but if this is considered 
optional there is do defined meaning to a signature.

If you as DAM do not have a problem if DDs have own policies that do not 
require checking a government issued photo ID, then I do not see why the 
key signing requirement exists at all.

> Enrico

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#11971

Hi,

On 07.08.20 15:46, Adrian Bunk wrote:
> On Thu, Aug 06, 2020 at 05:54:21PM +0200, Enrico Zini wrote:

>> ...
>> As DAM, I would have a problem if someone automatically signed the keys
>> of every stanger who asked them nicely in an email. At the same time, I
>> am open to the idea of policies that do not require meeting people in
>> person.
>> ...
> 
> Why are you requiring key signing at all when it has no defined semantics?
> 
> Many DDs check only the government issued photo ID for signing a key and 
> this is also how keysigning parties work, but if this is considered 
> optional there is do defined meaning to a signature.
> 
> If you as DAM do not have a problem if DDs have own policies that do not 
> require checking a government issued photo ID, then I do not see why the 
> key signing requirement exists at all.

This is not something that DAM decides, hence we are having this
discussion here, with the goal of obtaining a shared understanding of
the current requirements, policies, and practices.

- ulrike

[toc] | [prev] | [next] | [standalone]

#11985

Adrian Bunk dijo [Fri, Aug 07, 2020 at 04:46:18PM +0300]:
> Why are you requiring key signing at all when it has no defined semantics?
> 
> Many DDs check only the government issued photo ID for signing a key and 
> this is also how keysigning parties work, but if this is considered 
> optional there is do defined meaning to a signature.
> 
> If you as DAM do not have a problem if DDs have own policies that do not 
> require checking a government issued photo ID, then I do not see why the 
> key signing requirement exists at all.

FWIW, and as I said in my other mail - Each of the three keyring-maint
members have different policies.

The word "trust" also has many different meanings and values, but we
treat it as a binary thing here - Do two people trust the person
controlling 0x0000DEADBEEF0000 to be Gunnar Wolf or not? If so, we
accept. If not, we don't. And yes, we have made some exceptions and
jumped through some hoops to adapt to reality, but that's the trust
level we can impose without our requirements breaking down into chaos.

We had quite a hard time in 2015 when we did the <2048b purge. But we
managed not to loosen our requirements.

[toc] | [prev] | [next] | [standalone]

#11989

On Sun, Aug 09, 2020 at 12:20:53AM -0500, Gunnar Wolf wrote:
> Adrian Bunk dijo [Fri, Aug 07, 2020 at 04:46:18PM +0300]:
> > Why are you requiring key signing at all when it has no defined semantics?
> > 
> > Many DDs check only the government issued photo ID for signing a key and 
> > this is also how keysigning parties work, but if this is considered 
> > optional there is do defined meaning to a signature.
> > 
> > If you as DAM do not have a problem if DDs have own policies that do not 
> > require checking a government issued photo ID, then I do not see why the 
> > key signing requirement exists at all.
> 
> FWIW, and as I said in my other mail - Each of the three keyring-maint
> members have different policies.
> 
> The word "trust" also has many different meanings and values, but we
> treat it as a binary thing here - Do two people trust the person
> controlling 0x0000DEADBEEF0000 to be Gunnar Wolf or not?
>...

What is the reason for this mapping of a key to a non-unique name?

The point can be made that Debian should know the legal name of
the people who are allowed to upload to the archive.

But this is defeated if it is permitted that I instead just certify by 
signing the key that I trust the person controlling 0x0000DEADBEEF0000 
is some real-life or online person using the name Gunnar Wolf without
verifying against a government issued photo ID.

If this is permitted, then anyone advocating for DM or DD should be 
expected to sign the key without checking any ID.
If I trust you to upload to the archive, then I should also trust 
that you are who you claim to be.

And without a strong reason for requiring identity verification,
the main "benefit" of the requirement of 2 signatures for which
most DDs require in-person meeting is that it reduces diversity
in Debian.

When you need signatures in a place with many DDs, you just check 
when and where the local open source meetup is, go there, and ask
who is a DD.
I can offer first-hand experience that this works.
And the two local DDs I knew from non-Debian contexts were not
even present.

But in places that do not already have too many DDs,
getting signatures can require real effort and expenses.

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#11984

[Multipart message — attachments visible in raw view] — view raw

Hello Enrico, and thanks for bringing the discussion over here.

Enrico Zini dijo [Thu, Aug 06, 2020 at 05:54:21PM +0200]:
> Hello,
> 
> we have people approaching Debian with a lack of GPG signatures, and we
> generally cannot ask them to travel and meet other developers in person
> to get their key signed.
> 
> Technically, we are not requiring that people meet a DD in person, only
> that people have their key signed by a DD.
> 
> Technically, every DD has their own policies for signing keys, which
> could go from not requiring meeting in person at all, to requiring to
> meet in person multiple times. It might require to check a government
> issued photo ID, or it might not.
> 
> Practically, I feel like most of the time people's policies match what
> are the perceived expectations of the rest of the project. Meeting in
> person has always been a good safe bet, if only for the reson that it's
> been accepted without question for many years.
> 
> It's time to review those expectations.
> (...)

Enrico brought up this topic to DPL, DAM, front-desk and keyring-maint
about two weeks ago. I will copy over what I answered back then:

    We have been rehashing many of the (great) arguments you present
    every now and then since... At least, I remember the point being
    brought up after the Yuge KSP from HEL at DC5, and the
    Transnational Republic incident of DC6.

    Our guidelines have been for many many many years that "everybody
    is free to set their own policy — but please be sensible and
    careful". We have never sent out an official announcement, either
    from DAM or from keyring-maint, about it... but AIUI we have been
    basically in agreement and explicitly said so at KSP introductions
    (I have, repeatedly).

    We have often mentioned positive examples (i.e. pseudonymous
    community members we completely trust). We have mentioned the ease
    to acquire forged or plainly fake official-looking IDs.

So, where do I stand? I try not to sign keys for people I cannot
recognize without looking at their papers. That means, my signing
resembles a lot my group of friends, the group of peple we meet year
after year in DebConf, plus some others I've bumped into now and
then. IDs? Show them to me, I don't really mind, I have done many
signings without looking at IDs. I know first-hand¹ that forging them
is very easy.

I also know some of our friends have a made-up identity. Some of those
identities are close to twenty years old, at least. That's worth the
same as a birth-given name in my book...

And yes, I have often refused to sign people's keys when they approach
me at a DebConf if we have not held significative interactions in the
past. I usually insist that I do not sign at a first
meeting. Although, yes, if meeting somebody at other ocassions,
specially given Latin America is a quite PGP-sparse region... I tend
to be a bit more flexible, to aid people getting connected and start
contributing.

And... Well, to the point at hand: Yes, I do think we have to rethink
our policies. I don't have an answer right now, and most likely, I
won't sign any keys during this DebConf. But as more of our activities
are conducted online, we will have to start trusting videoconferences
to prove identities.

(of course... given deepfakes have been getting better and
better... who knows? :-\ )

¹ If you must know, >25 years ago I paid for a passport I should not
  have received. My personal data was correct, but back then, my
  country required a military service "clearance" I didn't have. I am
  not proud of having paid for an illegal document, and would not do
  it again. But it's part of what I learnt, and I am sure my
  experience would not change _too much_ going to other
  countries. More money to spend, perhaps...

[toc] | [prev] | [next] | [standalone]

#11990

[Multipart message — attachments visible in raw view] — view raw

Enrico Zini wrote:

> we have people approaching Debian with a lack of GPG signatures, and we
> generally cannot ask them to travel and meet other developers in person
> to get their key signed.

It's worthwhile stating the actual problem that is trying to be solved
here.

I believe that is: "Given difficulties with keysigning in the modern
environment, what does the project believe is the appropriate
verification of identification before we allow someone access to our
systems, the ability to upload packages and/or the ability to vote
within the project".

For a long time our default approach has been that a sufficiently signed
PGP key is our bar, with occasional exceptions when alternative
verification has been performed (I know in the past DAM has phoned
applicants when it has been impossible for them to obtain signatures).

Key signing has been creaking for a while, and I'm conscious even before
COVID-19 it was a bar that made things difficult for some applicants.
Equally DAM phoning everyone does not scale (and I'm not even sure how
it adds a significant extra level of assurance).

I worry that by framing this discussion in terms of "what would be an
acceptable weakening of our keysigning requirements" we are losing the
benefit we gain from keysigning, and avoiding the actual problem we want
to solve.

J.

-- 
] https://www.earth.li/~noodles/ []  If a program is useless, it must  [
]  PGP/GPG Key @ the.earth.li    []           be documented.           [
] via keyserver, web or email.   []                                    [
] RSA: 4096/0x94FA372B2DA8B985   []                                    [

[toc] | [prev] | [next] | [standalone]

#11993 — Re: Expressing regrets for how I handled the transition to Identity Verification in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Jonathan" == Jonathan McDowell <noodles@earth.li> writes:


    Jonathan> It's worthwhile stating the actual problem that is trying
    Jonathan> to be solved here.

    Jonathan> I believe that is: "Given difficulties with keysigning in
    Jonathan> the modern environment, what does the project believe is
    Jonathan> the appropriate verification of identification before we
    Jonathan> allow someone access to our systems, the ability to upload
    Jonathan> packages and/or the ability to vote within the project".

I think exploring this broader statement of the problem makes sense
(although I would have been happier if you had changed the subject:-)

I'd like to take a moment to express regret and what I've learned that I
can improve with the interaction I had with Olek .  I deeply regret that
Olek walked away from that interaction feeling like I was dismissing his
ideas including the idea of exploring the broader identity context.  I
regret that I allowed my frustration to get in the way of clearly
articulating my concern, because had I done that I would likely have
realized that I didn't have evidence Olek was taking the position I
thought added stop energy.

So, I think that exploring the broader concept of identity verification
is valuable and I think we've reached a point where it makes sense to do
that.

What frustrated me is the idea of holding back what appeared to be a
productive short-term discussion where we were getting valuable advice
and input and blocking that short-term success on a long drawn-out
discussion where no one had any concrete suggestions yet.  I do think
the longer-term discussion is valuable.
But I also strongly believe that when people are having useful input
that will help them today, we as a project shouldn't get in their way
with our long-term thinking.

I don't think you're trying to do that.  I don't think Olek was trying
to do that.
As someone who as organized these discussions, when someone jumps in
with  a proposal to reframe things with a much broader scope, it does
have the effect of slowing things down.
But the broader discussions are valuable, and Debian really does think
about the long-term.

Again, as someone who has run these discussions and felt the frustration
of how hard it can be to make decisions in Debian, simple things like
changing subject lines and waiting a bit can help so much.
Re reading the discussion, even by the time Olek wrote his  first
message, I think the timing was totally fine and we'd already gotten the
short-term actionable input we were going to get.

I do hope that as a community we eventually move toward a culture where
we expect ourselves to do things like change subjects, think about the
timing of broadening scope, and think about how we can make decisions
and get input more efficiently.

And so I do strongly stand behind the idea that we shouldn't block the
short-term on the long term.  I wish that I had found more constructive
ways of asking Olek for reassurance that he wasn't trying to block
short-term progress.
I think that based on an off-list discussion with Olek and thinking
about the situation I've found better mechanisms to do that in the
future.

--Sam

[toc] | [prev] | [next] | [standalone]

#11991 — Re: Potential Summary: Keysigning in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

Enrico, I find that the sorts of discussions that you've  started are
more valuable if someone goes back later and tries to summarize what
we've learned.
So I'm going to take a stab at that.

I don't think we were seeking a consensus, and we didn't find one.  What
we did find is a number of approaches that seem to have sufficient
support.  If one of those works for you as a person contemplating
signing a key, my take is that you should go for it.

We received a number of different suggestions:

* We could look at adopting some sort of more formal web of
  trust--sometimes permitting non-DD signatures  to count toward trust
  in our key ring [Roberto C. Sánchez ]

* There was a fair bit of discussion about video meetings.  In general
  many people seemed to believe that these could be adequate.  The
  counter argument is that it is difficult/impossible to explore the
  security features of government ID over such a meeting.  Several
  people pointed out that most of us don't know how to test those
  security features anyway.  I'd say that video meetings seem to have
  sufficient support that if you as an individual feel that meets your
  signing policy, go for it.

* We had several people asking what value a government ID gives to us
  and suggesting that perhaps signing a long-established identity with a
  proven track record of work is acceptable.

* Jonas provided a concrete suggestion for a rule that can apply in
  Covid although it does mean spending far more time interacting with
  people than someone who is anxious to get their key signed might want:

>A rule that I try to apply for my key-signing, and which I think ties 
>into your interesting reflections here, is that I will sign the key of 
>someone whom I feel I would be able to recognize if randomly bumping 
>into them years later on a bus.

>It forces me to try pay attention to the person for long enough that 
>they make a (hopefully) lasting impression on me.  Often I suggest that 
>we sit for a moment and they tell something about themselves.  Not an 
>interview or a test, just as an aid in etching an impression.  Sometimes 
>we end up hanging out for longer than "needed".  Sometimes the 
>atmosphere is too hectic and we cannot find the calm to tune in - and 
>then delay the "session".

* Several people questioned whether government issued IDs are helpful.


* We've had parts of this  discussion before; see     https://lists.debian.org/debian-project/2015/02/msg00017.html

* Didier proposed another concrete rule that can work in the current times:

>The line I try to stick with is "crowd knowledge": is this person I'm about to 
>sign the key of "known" as the name they claim to carry? Does their key "name" 
>correspond to one or some of the names they go by? In recent times (during 
>which physical encounters were still a possibility), I have actually asked 
>someone else around "can you tell me the name of this person I'm about to sign 
>the key of?" I have also often had a very small chit-chat: "what do you do in 
>Debian / free software?", "what brought you here?". It's not an interview per 
>se, but answers still matter.

* Jonas pointed out that competence is different from authenticity.  It
is explicitly important that people be represented by a single
identifier.

* I expanded on that.  We want to make it expensive for someone to build
  up an identifier with reputation and to risk that reputation by
  attacking Debian's integrity.  That is, people spending a year to
  build trust and then burning that to get malicious artifacts into
  Debian is an attack I think we should care about.  Binding identity
  back to a real world identity is one way to make this much more
  expensive.  Each person only gets one real-world identity.  If
  checking government IDs helps with that, then doing so can be useful.
  I point out that Jonas's rule is another way to accomplish the same.

* Adrian Bunk indicated he thought that checking government IDs was an
  explicit requirement of all our key signings.  It's clear from the
  discussion that's not the case.  He then asked what the value was at
  all if there is not a single consistent approach.  We kind of left him
  hanging without an answer.

* Olek Wojnar  and Jonathan McDowell  proposed reframing the discussion
  in terms of our approach to identity verification rather than in terms
  of key signing policy.
  

[toc] | [prev] | [next] | [standalone]

#11992 — Re: Potential Summary: Keysigning in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

Quoting Sam Hartman (2020-08-12 13:59:07)
> Enrico, I find that the sorts of discussions that you've  started are
> more valuable if someone goes back later and tries to summarize what
> we've learned.
> So I'm going to take a stab at that.

Thanks, Sam - I find such summary quite helpful!

...even for a thread that I _did_ follow closely, in a calm setting¹

Amazing if someone should feel like doing this kind of summary for other 
threads as well.


 - Jonas


¹ Something on Orø, Denmark slows down time to a pleasant pace - you are 
all very welcome to come experience it, virtually or in person!

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#11996 — Re: Potential Summary: Keysigning in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

Thanks for the summary, Sam.

As an 'amicus' of the project, and interested on these topics, I wanted
to provide my 2 cents.


First of all, you are not the only one with this situation. The issue
arises from the vague meaning of a signature on a pgp key, and also
appears on other venues when using a network of pgp signatures. Be that
"the" WoT or an internal one of DD, as soon as you have many people
acting as introducers, with slightly different criteria, it ends up with
a somewhat diffuse meaning.

I do think it is important to define what are the objectives of the
Developers PGP keys. Is it to ensure that the same online entity is
responsible for all the uploads of that named individual? So that if
there is some questionable action it can be traced back to the
responsible individual? To make it hard to "game" the project? To have a
single identifier?


On the topic of malicious activity, I should note that, while it is
important that there is a cost of entry that would be "burned" by
activities that went to undermine the project goal, and certainly a
zero-cost approach would attract many trolls, it is not impossible for a
determined attacker:

- A single determined individual might be able to get several identities
by identifying through different DD, either under the same or different
alias. I'd also not consider entirely true that "Each person only gets
one real-world identity", but I don't think corner cases would be
needed, when cleverly presenting itself through different introducers
could probably get them in.

- A 'company' that had a specific interest to weaken Debian (perhaps so
that its systems are easier to compromise, or because it competes with
their own products), to the point of tasking a number of individuals to
that end. This would probably be a bigger threat than the previous one
as there would be an external motivation to do that which is financing
such activity. Please note that by 'company' I am not meaning just
business entities, but also three letter agencies, nation states,
malicious hacker groups, mafia...
Even ignoring the (likely) ability of such groups to get a passport
under a name different than the one given at birth to an individual,
it seems they would have little trouble to produce a new identity to
present to Debian. I assume they would probably only have a few people
on payroll with the required expertise tasked to infiltrate into the
project, *however* it would be very easy to let them assume online the
identity of any other employee (such as a non-technical receptionist),
which would be plenty if compared to the number of "ghosthacker
developers".




Finally, some technical points:

* PGP signatures can include notations. The main problem is that they
are not standardized, but a number of them could be defined with the
desired meanings "I have checked a Government ID", "Online only", "Long
time online interaction", "COVID-19", "Verified that the key owner has
access to the associated email", "Group key"

* PGP signatures can include an expiration. It is often the case that it
is set to the key expiration, but it would be possible to sign a key for
only a few months (considering that after that time it will be possible
to meet IRL again). 

* The piece about matching them with a legal identity (the equivalent to
verify a Passport) could be done through the Government eID, at least
for those in the European Union (see eIDAS regulation). It may be
possible to generalise it to other countries through ePassport.
Probably "fun" to make it work (both the client and the verification
part), but a PGP key cryptographically linked to the Government PKI
would be more than a DD looking at a passport.


Best regards

Ángel

[toc] | [prev] | [next] | [standalone]

#12003 — Re: Potential Summary: Keysigning in times of COVID-19

On Thu, Aug 13, 2020 at 02:59:59AM +0200, Ángel wrote:
> as there would be an external motivation to do that which is financing
> such activity. Please note that by 'company' I am not meaning just
> business entities, but also three letter agencies, nation states,
> malicious hacker groups, mafia...
> Even ignoring the (likely) ability of such groups to get a passport
> under a name different than the one given at birth to an individual,
> it seems they would have little trouble to produce a new identity to
> present to Debian. I assume they would probably only have a few people
> on payroll with the required expertise tasked to infiltrate into the
> project, *however* it would be very easy to let them assume online the
> identity of any other employee (such as a non-technical receptionist),
> which would be plenty if compared to the number of "ghosthacker
> developers".

I don't get where people get the feeling that producing a passport would
require a TLA/nation state/organized crime/etc.  You can get one for
peanuts.

I've been offered one once, and I inquired about the details -- for just
~$25 (100PLN) the guy claimed it's done on original booklet, etc.  That's
stuff for fooling actual government officials.  No need to sacrifice that
whole $25 to get a fake for Debian purposes, though -- no one among us can
tell apart one booklet/card with a badly-made photo from another.

Waving a passport or similar id offers laughable security.


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#12005 — Re: Potential Summary: Keysigning in times of COVID-19

On Thu, Aug 13, 2020 at 17:57, Adam Borowski <kilobyte@angband.pl> 
wrote:
> I don't get where people get the feeling that producing a passport 
> would
> require a TLA/nation state/organized crime/etc.  You can get one for
> peanuts.
> 
> I've been offered one once, and I inquired about the details -- for 
> just
> ~$25 (100PLN) the guy claimed it's done on original booklet, etc.  
> That's
> stuff for fooling actual government officials.  No need to sacrifice 
> that
> whole $25 to get a fake for Debian purposes, though -- no one among 
> us can
> tell apart one booklet/card with a badly-made photo from another.
> 
> Waving a passport or similar id offers laughable security.

I think the point about fake idenity documents is, it being a criminal 
activity and make one liable for prosecution. So it is not just about 
immediate cost of getting a fake id, but the is high risk if you are 
caught. Not all frauds get caught, but some do get caught and it 
probably serves as a deterrant or it sufficiently sets the bar very 
high (I think 3 letter agencies can still take the risk).

[toc] | [prev] | [next] | [standalone]

#12006 — Re: Potential Summary: Keysigning in times of COVID-19

On Thu, Aug 13, 2020 at 11:08:01PM +0530, Pirate Praveen wrote:
> I think the point about fake idenity documents is, it being a criminal
> activity and make one liable for prosecution. So it is not just about
> immediate cost of getting a fake id, but the is high risk if you are caught.
> Not all frauds get caught, but some do get caught and it probably serves as
> a deterrant or it sufficiently sets the bar very high (I think 3 letter
> agencies can still take the risk).

I don't think someone could possibly be prosecuted for using a fake passport
to obtain a gpg signature.  Especially with the link between meeting a DD
many months earlier and that criminal betrayal being so tenuous.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#12008 — Re: Potential Summary: Keysigning in times of COVID-19

On Thu, Aug 13, 2020 at 09:03:00PM +0200, Adam Borowski wrote:
>On Thu, Aug 13, 2020 at 11:08:01PM +0530, Pirate Praveen wrote:
>> I think the point about fake idenity documents is, it being a criminal
>> activity and make one liable for prosecution. So it is not just about
>> immediate cost of getting a fake id, but the is high risk if you are caught.
>> Not all frauds get caught, but some do get caught and it probably serves as
>> a deterrant or it sufficiently sets the bar very high (I think 3 letter
>> agencies can still take the risk).
>
>I don't think someone could possibly be prosecuted for using a fake passport
>to obtain a gpg signature.  Especially with the link between meeting a DD
>many months earlier and that criminal betrayal being so tenuous.

It's clearly fraudulent under at least UK law. I'm sure it would also
be elsewhere. You might struggle to get police to pick up the *case*,
but...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

[toc] | [prev] | [next] | [standalone]

#12020 — Re: Potential Summary: Keysigning in times of COVID-19

On Thu, Aug 13, 2020 at 09:23:58PM +0100, Steve McIntyre wrote:
> On Thu, Aug 13, 2020 at 09:03:00PM +0200, Adam Borowski wrote:
> >On Thu, Aug 13, 2020 at 11:08:01PM +0530, Pirate Praveen wrote:
> >> I think the point about fake idenity documents is, it being a criminal
> >> activity and make one liable for prosecution. So it is not just about
> >> immediate cost of getting a fake id, but the is high risk if you are caught.
> >> Not all frauds get caught, but some do get caught and it probably serves as
> >> a deterrant or it sufficiently sets the bar very high (I think 3 letter
> >> agencies can still take the risk).
> >
> >I don't think someone could possibly be prosecuted for using a fake passport
> >to obtain a gpg signature.  Especially with the link between meeting a DD
> >many months earlier and that criminal betrayal being so tenuous.
> 
> It's clearly fraudulent under at least UK law. I'm sure it would also
> be elsewhere. You might struggle to get police to pick up the *case*,
> but...

This does not even matter when there are DDs who sign keys with fake 
names that are not printed on any (real or fake) government documents...

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#12021 — Re: Potential Summary: Keysigning in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

Quoting Adrian Bunk (2020-08-14 18:33:06)
> On Thu, Aug 13, 2020 at 09:23:58PM +0100, Steve McIntyre wrote:
> > On Thu, Aug 13, 2020 at 09:03:00PM +0200, Adam Borowski wrote:
> > >On Thu, Aug 13, 2020 at 11:08:01PM +0530, Pirate Praveen wrote:
> > >> I think the point about fake idenity documents is, it being a 
> > >> criminal activity and make one liable for prosecution. So it is 
> > >> not just about immediate cost of getting a fake id, but the is 
> > >> high risk if you are caught. Not all frauds get caught, but some 
> > >> do get caught and it probably serves as a deterrant or it 
> > >> sufficiently sets the bar very high (I think 3 letter agencies 
> > >> can still take the risk).
> > >
> > >I don't think someone could possibly be prosecuted for using a fake 
> > >passport to obtain a gpg signature.  Especially with the link 
> > >between meeting a DD many months earlier and that criminal betrayal 
> > >being so tenuous.
> > 
> > It's clearly fraudulent under at least UK law. I'm sure it would 
> > also be elsewhere. You might struggle to get police to pick up the 
> > *case*, but...
> 
> This does not even matter when there are DDs who sign keys with fake 
> names that are not printed on any (real or fake) government 
> documents...

Seems we are talking about several things here:

 a) trusting an identity _without_ relying on governmental proof

 b) proving an identity using fake governmental proof

It is my understanding that a) is illegal and punishable in many legal 
jurisdictions.

It is my understanding that b) is currently tolerated in Debian but only 
exceptionally, and we are currently discussing if we should tolerate it 
more generally.

I do believe that a) matters for Debian in discussing b), because the 
risk of punishment is an expense, and the more expensive it is to twist 
and bend rules the more likely those rules are followed and can 
therefore be trusted.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#12022 — Re: Potential Summary: Keysigning in times of COVID-19

On 2020-08-14 at 20:27 +0200, Jonas Smedegaard wrote:
> Seems we are talking about several things here:
> 
>  a) trusting an identity _without_ relying on governmental proof
> 
>  b) proving an identity using fake governmental proof
> 
> It is my understanding that a) is illegal and punishable in many
> legal 
> jurisdictions.
> 
> It is my understanding that b) is currently tolerated in Debian but
> only 
> exceptionally, and we are currently discussing if we should tolerate
> it 
> more generally.
> 
> I do believe that a) matters for Debian in discussing b), because the 
> risk of punishment is an expense, and the more expensive it is to
> twist 
> and bend rules the more likely those rules are followed and can 
> therefore be trusted.
> 
> 
>  - Jonas

I think you meant to order them the opposite way...

[toc] | [prev] | [next] | [standalone]

#12023 — Re: Potential Summary: Keysigning in times of COVID-19

[Multipart message — attachments visible in raw view] — view raw

Quoting Ángel (2020-08-14 22:57:32)
> On 2020-08-14 at 20:27 +0200, Jonas Smedegaard wrote:
> > Seems we are talking about several things here:
> > 
> >  a) trusting an identity _without_ relying on governmental proof
> > 
> >  b) proving an identity using fake governmental proof
> > 
> > It is my understanding that a) is illegal and punishable in many 
> > legal jurisdictions.
> > 
> > It is my understanding that b) is currently tolerated in Debian but 
> > only exceptionally, and we are currently discussing if we should 
> > tolerate it more generally.
> > 
> > I do believe that a) matters for Debian in discussing b), because 
> > the risk of punishment is an expense, and the more expensive it is 
> > to twist and bend rules the more likely those rules are followed and 
> > can therefore be trusted.

> I think you meant to order them the opposite way...

Whoops, yeah.  Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web