Re: Keysigning in times of COVID-19

[Florian Weimer]

* Philip Hands:

> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.

Even if you got a peer-reviewed research paper out of it?  (If I
recall correctly, academics already set up a fake Debian mirror and
wrote a paper about it.)

Re: Keysigning in times of COVID-19

[Russ Allbery]

Jonas Smedegaard  writes:

> Any opinion on the "votes twice" part? Anyone?

How many decisions have we had that were decided by a slim enough margin
that you believe fraud could have changed the outcome?

What have we voted on that you think anyone would care sufficiently about
to do the tedious and time-consuming work required to get a fake identity
with voting privileges?

I'm dubious of the threat model.  Injecting malicious code into the
archive seems to have a far, far higher reward to effort ratio than voting
in our rare and generally not very close project votes.

-- 
Russ Allbery (r...@debian.org)  

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Philip Hands (2020-08-20 10:05:42)
> rhkra...@gmail.com writes:
> 
> > On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote:
> >> If the term "malicious DD" is reasonable, we have a bigger problem 
> >> than "votes twice" or "uploads a backdoor".
> >> 
> >> aka, "a malicious DD exists" is already a problem.
> >
> > Do you have a suggested solution?
> >
> > I believe there are circumstances in which a non-malicious DD could 
> > evolve to a malicious DD.
> >
> > Or that a malicious DD could be very hard to detect if he didn't 
> > want to be detected (e.g., sociopath / psychopath).
> 
> Conjuring up a "mallicious DD" seems to carry with it the assumption 
> that only bad people do bad things, which seems naive to me.
> 
> This conversation reminds me of the trade-offs involved in airport 
> security.
> 
> One can decide to spend money on security theatre (e.g. expensive 
> scanners) or general resilience (e.g. more ambulances and emergency 
> responders). The former are much easier to point at, but the latter do 
> more to save lives because people having a medical emergency while 
> queing for checkin is _way_ more common than someone with actual 
> terrorist intent deciding to try to sneak an actual weapon through 
> security.
> 
> In this situation, tightening up our proceedures regarding keys 
> strikes me as much closer to the security theater end of the spectrum, 
> while efforts like Reproducible Builds are at the general resilience 
> end.
> 
> If I were a sociopath contemplating sabotage in the Free Software 
> sphere, going to the effort of becoming a DD, even for the first time, 
> would be nowhere near the top of my list.
> 
> Does DAM actually have any cases at all where they suspect a 
> previously expelled DD of trying to sneak back into the project under 
> a new ID?
> 
> If not, then either our proceedures are already broken enough that 
> temproarily slackening keysigning protocols won't make the slightest 
> difference, or the threat is probably not worth worrying about.

Seems to me you are addressing only the "uploads a backdoor".

Any opinion on the "votes twice" part? Anyone?


 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Ansgar]

On Thu, 2020-08-20 at 10:05 +0200, Philip Hands wrote:
> Conjuring up a "mallicious DD" seems to carry with it the assumption
> that only bad people do bad things, which seems naive to me.
> 
> This conversation reminds me of the trade-offs involved in airport
> security.
> 
> One can decide to spend money on security theatre (e.g. expensive
> scanners) or general resilience (e.g. more ambulances and emergency
> responders)

The number of airplane hijackings has gone down significantly[1] while
the amount of air travel has increased by a lot (passenger-kilometers
per year by more than factor 10 or so between 1970 and 2010 from some
graph I found).  So it seems to be effective.

Maybe the "security theater" even pays for itself given planes are
fairly expensive? :-)

  [1]: 
https://www.statista.com/chart/4560/airliner-hijackings-have-become-rare-events/

> In this situation, tightening up our proceedures regarding keys strikes
> me as much closer to the security theater end of the spectrum, while
> efforts like Reproducible Builds are at the general resilience end.

One could just do both.  I think I have seen, for example, automated
external defibrillators in public buildings like airports.

> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.
> 
> Does DAM actually have any cases at all where they suspect a previously
> expelled DD of trying to sneak back into the project under a new ID?
> 
> If not, then either our proceedures are already broken enough that
> temproarily slackening keysigning protocols won't make the slightest
> difference, or the threat is probably not worth worrying about.

If a fire alarm wasn't triggered by a fire for some time, should it be
removed? Maybe the procedures just work reasonably well.

Ansgar

Re: Keysigning in times of COVID-19

[Andrey Rahmatullin]

On Thu, Aug 20, 2020 at 10:05:42AM +0200, Philip Hands wrote:
> If I were a sociopath contemplating sabotage in the Free Software
> sphere, going to the effort of becoming a DD, even for the first time,
> would be nowhere near the top of my list.
Indeed, I would sabotage some upstream code directly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Philip Hands]

rhkra...@gmail.com writes:

> On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote:
>> If the term "malicious DD" is reasonable, we have a bigger problem than
>> "votes twice" or "uploads a backdoor".
>> 
>> aka, "a malicious DD exists" is already a problem.
>
> Do you have a suggested solution?
>
> I believe there are circumstances in which a non-malicious DD could evolve to 
> a malicious DD.
>
> Or that a malicious DD could be very hard to detect if he didn't want to be 
> detected (e.g., sociopath / psychopath).

Conjuring up a "mallicious DD" seems to carry with it the assumption
that only bad people do bad things, which seems naive to me.

This conversation reminds me of the trade-offs involved in airport
security.

One can decide to spend money on security theatre (e.g. expensive
scanners) or general resilience (e.g. more ambulances and emergency
responders). The former are much easier to point at, but the latter do
more to save lives because people having a medical emergency while
queing for checkin is _way_ more common than someone with actual
terrorist intent deciding to try to sneak an actual weapon through
security.

In this situation, tightening up our proceedures regarding keys strikes
me as much closer to the security theater end of the spectrum, while
efforts like Reproducible Builds are at the general resilience end.

If I were a sociopath contemplating sabotage in the Free Software
sphere, going to the effort of becoming a DD, even for the first time,
would be nowhere near the top of my list.

Does DAM actually have any cases at all where they suspect a previously
expelled DD of trying to sneak back into the project under a new ID?

If not, then either our proceedures are already broken enough that
temproarily slackening keysigning protocols won't make the slightest
difference, or the threat is probably not worth worrying about.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[rhkramer]

On Wednesday, August 19, 2020 09:33:04 AM Wouter Verhelst wrote:
> If the term "malicious DD" is reasonable, we have a bigger problem than
> "votes twice" or "uploads a backdoor".
> 
> aka, "a malicious DD exists" is already a problem.

Do you have a suggested solution?

I believe there are circumstances in which a non-malicious DD could evolve to 
a malicious DD.

Or that a malicious DD could be very hard to detect if he didn't want to be 
detected (e.g., sociopath / psychopath).

Re: Keysigning in times of COVID-19

[Wouter Verhelst]

On Mon, Aug 17, 2020 at 08:39:02PM +0200, Jonas Smedegaard wrote:
> Quoting Federico Ceratto (2020-08-17 20:17:49)
> > On Thu, Aug 6, 2020 at 5:40 PM Roberto C. Sánchez  
> > wrote:
> > > Perhaps instead of requiring "a valid DD signature" as the basis for
> > > "important" project actions (e.g., uploading to the archive), we should
> > > consider rather "degree of trust associated with a collection of one or
> > > more signatures".
> > 
> > Forking the conversation a bit, I'm wondering what is the real threat
> > that we want to mitigate.
> > I guess the main one is: "a malicious DD uploads a package containing
> > a backdoor"
> 
> Also: "a malicious DD votes twice"

If the term "malicious DD" is reasonable, we have a bigger problem than "votes
twice" or "uploads a backdoor".

aka, "a malicious DD exists" is already a problem.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Federico Ceratto (2020-08-17 20:17:49)
> On Thu, Aug 6, 2020 at 5:40 PM Roberto C. Sánchez  wrote:
> > Perhaps instead of requiring "a valid DD signature" as the basis for
> > "important" project actions (e.g., uploading to the archive), we should
> > consider rather "degree of trust associated with a collection of one or
> > more signatures".
> 
> Forking the conversation a bit, I'm wondering what is the real threat
> that we want to mitigate.
> I guess the main one is: "a malicious DD uploads a package containing
> a backdoor"

Also: "a malicious DD votes twice"

 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Federico Ceratto]

On Thu, Aug 6, 2020 at 5:40 PM Roberto C. Sánchez  wrote:
> Perhaps instead of requiring "a valid DD signature" as the basis for
> "important" project actions (e.g., uploading to the archive), we should
> consider rather "degree of trust associated with a collection of one or
> more signatures".

Forking the conversation a bit, I'm wondering what is the real threat
that we want to mitigate.
I guess the main one is: "a malicious DD uploads a package containing
a backdoor"

I propose a crude risk metric for uploads that can be generated and
used automatically:

Risk multipliers:
- Package popcon: a backdoor in a popular packages has higher impact
- Change size in SLOC: makes it easier to sneak in a backdoor
- Is it a binary upload?
- Is it a NMU? Is it the first NMU of such DD against such package?
- Is the uploader a DD or DM?

Risk dividers:
- Number of signatures on the uploader's GPG key
- Number of days since the uploader's NM process (can make the
malicious DD way less effective)
- Number of packages maintained by the uploader (perhaps?)
- NMU delay in days (perhaps?)

Very high-risk uploads could require an approval from a second DD.
As an added benefit, this makes our workstations and GPG keys less
interesting targets for attackers.
It could make DDs less likely to be coerced by legal means, work
pressure, or other.
Perhaps it might also simplify the progress between sponsored
maintainer -> DM -> DD and
encourage good practices.

Any risk equation can be debated endlessly... but it seems like an
improvement over what we have.

Thanks!
--
Federico

Re: Keysigning in times of COVID-19

[Pierre-Elliott Bécue]

Le vendredi 14 août 2020 à 01:10:02+0200, Ángel a écrit :
> On 2020-08-13 at 16:43 +0200, Pierre-Elliott Bécue wrote:
> > > gpg has a `--ask-cert-expire` flag and a `--default-cert-expire` 
> > > option in that effect.  Expired certification signatures will be 
> > > ignored when building the Web of Trust.
> > > 
> > > Cheers
> > 
> > This could work, but we'd have to handle the case when developers
> > forget to set a signature as time-limited/don't follow this thread and
> > never care to set it up.
> > 
> > I'd rather avoid relying on signatures, than making the meaning of
> > signature quite less tangible.
> 
> 
> I don't see your point. We have a general standard or what to require
> for signing, and this thread started asking about weaking them due to
> the pandemic.
> 
> Limiting the time the signature is valid is a time-limited way to do
> that. And it is a cryptographic one, which is a very nice feature.
> I would like to have some common notation so that the standard used
> could be tracked, too.
> 
> If a developer is going to forget how to do a "weak value" signature, he
> should probably stick to the standards he has generally used, but
> anyway, if someone wanted to do a limited-time signature but forgot the
> parameter, he should do exactly the same as if he signed Eve key while
> intending to sing Alice's: revoke the wrong signature and create a new
> one.

I fully agree on the principle, but there is a big hiatus between what
some do with their GPG key and what others do.

Without being judgmental, I think this spectre of ways to do things has
to be taken into account before giving any project-wide directives
regarding identity certification.

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Potential Summary: Keysigning in times of COVID-19

[Jonas Smedegaard]

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

signature.asc
Description: signature

Re: Potential Summary: Keysigning in times of COVID-19

[Ángel]

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

Re: Potential Summary: Keysigning in times of COVID-19

[Jonas Smedegaard]

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

signature.asc
Description: signature

Re: Potential Summary: Keysigning in times of COVID-19

[Adrian Bunk]

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

Re: Keysigning in times of COVID-19

[Ángel]

On 2020-08-13 at 16:43 +0200, Pierre-Elliott Bécue wrote:
> > gpg has a `--ask-cert-expire` flag and a `--default-cert-expire` 
> > option in that effect.  Expired certification signatures will be 
> > ignored when building the Web of Trust.
> > 
> > Cheers
> 
> This could work, but we'd have to handle the case when developers
> forget to set a signature as time-limited/don't follow this thread and
> never care to set it up.
> 
> I'd rather avoid relying on signatures, than making the meaning of
> signature quite less tangible.


I don't see your point. We have a general standard or what to require
for signing, and this thread started asking about weaking them due to
the pandemic.

Limiting the time the signature is valid is a time-limited way to do
that. And it is a cryptographic one, which is a very nice feature.
I would like to have some common notation so that the standard used
could be tracked, too.

If a developer is going to forget how to do a "weak value" signature, he
should probably stick to the standards he has generally used, but
anyway, if someone wanted to do a limited-time signature but forgot the
parameter, he should do exactly the same as if he signed Eve key while
intending to sing Alice's: revoke the wrong signature and create a new
one.


Regards

Ángel




signature.asc
Description: This is a digitally signed message part

Re: Potential Summary: Keysigning in times of COVID-19

[Adam Borowski]

On Thu, Aug 13, 2020 at 10:59:47PM +0200, Christian Kastner wrote:
> On 2020-08-13 21:03, Adam Borowski wrote:
> > I don't think someone could possibly be prosecuted for using a fake passport
> > to obtain a gpg signature.

> But even if it weren't a crime: Once the person waving the fake ID is
> caught, it's unlikely that we'd see that person ever again at future
> Debian events, as that would probably result in a call to law enforcement.

Someone planning mischief won't attend a big event.

> You can't change your own face (within reason), and exposing that face
> is a risk.
> 
> You can easily discard an online persona and create a new one, though.

With ~1000 DDs, you can get 500 pairs of signatures without ever meeting the
same person twice.


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

Re: Potential Summary: Keysigning in times of COVID-19

[Christian Kastner]

On 2020-08-13 21:03, Adam Borowski wrote:
> I don't think someone could possibly be prosecuted for using a fake passport
> to obtain a gpg signature.

In many (if not most) jurisdictions, using a fake government ID for any
transaction whatsoever is a crime. It's not tied to monetary or any
other gain. The deterrent is meant to be absolute. Otherwise it wouldn't
be very effective.

But even if it weren't a crime: Once the person waving the fake ID is
caught, it's unlikely that we'd see that person ever again at future
Debian events, as that would probably result in a call to law enforcement.

You can't change your own face (within reason), and exposing that face
is a risk.

You can easily discard an online persona and create a new one, though.

Re: Potential Summary: Keysigning in times of COVID-19

[Steve McIntyre]

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.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Re: Potential Summary: Keysigning in times of COVID-19

[Ángel]

On 2020-08-13 at 17:57 +0200, Adam Borowski wrote:
> 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.

Hi

Please note that my point was that any determined 'company' could get
multiple identities signed, without even involving crafting new
passports or identity cards, which of course would also be within their
reach.

Would a TLA/nation state/organized crime/etc. be interested in being
able to compromise Debian hosts? Sure. Amongst them, some would try hard
for plausible deniability, while others directly don't care.

If the keysigning is expected to protect (to a certain point) against
this, it's a scenario to take into account, uncomfortable as it is.

It might be possible that there is a better solution for that that could
be included, or that it is determined that the system is fallible yet we
don't have anything better so far to use.

It is thus important to define what is expected from this step of the
process.

Best regards



signature.asc
Description: This is a digitally signed message part

Re: Potential Summary: Keysigning in times of COVID-19

[Adam Borowski]

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.
⠈⠳⣄

Re: Potential Summary: Keysigning in times of COVID-19

[Pirate Praveen]

On Thu, Aug 13, 2020 at 17:57, Adam Borowski  
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).

Re: Potential Summary: Keysigning in times of COVID-19

[Adam Borowski]

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.
⠈⠳⣄

Re: Keysigning in times of COVID-19

[Pierre-Elliott Bécue]

Le jeudi 13 août 2020 à 14:29:35+0200, Guilhem Moulin a écrit :
> Hi,
> 
> On Thu, 13 Aug 2020 at 14:11:14 +0200, Pierre-Elliott Bécue wrote:
> > Le jeudi 13 août 2020 à 07:42:29-0400, Sam Hartman a écrit :
> >>> "Paul" == Paul Wise  writes:
> >> 
> >>   Paul> On Wed, Aug 12, 2020 at 3:27 PM Pierre-Elliott Bécue wrote:
> >>   >> I'd rather try to solve the issue in a more sensible way : lower
> >>   >> the number of expected GPG signatures to 0 temporarily, and ask
> >>   >> for two or three advocacies from DDs.
> >> 
> >>   Paul> This seems like the most natural solution to the problem of
> >>   Paul> COVID mentioned thus far.
> >> 
> >> How do you feel about the idea of short-term expirations on signatures
> >> proposed in the previous message on the list?
> > 
> > Unless I missed a GPG capability, this seems kinda technically hard to
> > do.
> 
> gpg has a `--ask-cert-expire` flag and a `--default-cert-expire` option
> in that effect.  Expired certification signatures will be ignored when
> building the Web of Trust.
> 
> Cheers

This could work, but we'd have to handle the case when developers forget
to set a signature as time-limited/don't follow this thread and never
care to set it up.

I'd rather avoid relying on signatures, than making the meaning of
signature quite less tangible.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Guilhem Moulin]

Hi,

On Thu, 13 Aug 2020 at 14:11:14 +0200, Pierre-Elliott Bécue wrote:
> Le jeudi 13 août 2020 à 07:42:29-0400, Sam Hartman a écrit :
>>> "Paul" == Paul Wise  writes:
>> 
>>   Paul> On Wed, Aug 12, 2020 at 3:27 PM Pierre-Elliott Bécue wrote:
>>   >> I'd rather try to solve the issue in a more sensible way : lower
>>   >> the number of expected GPG signatures to 0 temporarily, and ask
>>   >> for two or three advocacies from DDs.
>> 
>>   Paul> This seems like the most natural solution to the problem of
>>   Paul> COVID mentioned thus far.
>> 
>> How do you feel about the idea of short-term expirations on signatures
>> proposed in the previous message on the list?
> 
> Unless I missed a GPG capability, this seems kinda technically hard to
> do.

gpg has a `--ask-cert-expire` flag and a `--default-cert-expire` option
in that effect.  Expired certification signatures will be ignored when
building the Web of Trust.

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Pierre-Elliott Bécue]

Le jeudi 13 août 2020 à 07:42:29-0400, Sam Hartman a écrit :
> > "Paul" == Paul Wise  writes:
> 
> Paul> On Wed, Aug 12, 2020 at 3:27 PM Pierre-Elliott Bécue wrote:
> >> I'd rather try to solve the issue in a more sensible way : lower
> >> the number of expected GPG signatures to 0 temporarily, and ask
> >> for two or three advocacies from DDs.
> 
> Paul> This seems like the most natural solution to the problem of
> Paul> COVID mentioned thus far.
> 
> How do you feel about the idea of short-term expirations on signatures
> proposed in the previous message on the list?

Unless I missed a GPG capability, this seems kinda technically hard to
do.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Pierre-Elliott Bécue]

Le jeudi 13 août 2020 à 03:36:11+, Paul Wise a écrit :
> > This wouldn't solve the broader issue that can arise when one lives in a
> > place with no close DD and wants to become a DD themselves.
> 
> Given the "problems" that are being discussed on another thread in
> another location, I think there is an obvious solution to solve both
> issues at the same time, once the COVID situation allows it.

Could you ellaborate a bit on this part, I feel that I have missed
something.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[rhkramer]

On Wednesday, August 12, 2020 11:36:11 PM Paul Wise wrote:
> Given the "problems" that are being discussed on another thread in
> another location, I think there is an obvious solution to solve both
> issues at the same time, once the COVID situation allows it.

??

Re: Keysigning in times of COVID-19

[Sam Hartman]

> "Paul" == Paul Wise  writes:

Paul> On Wed, Aug 12, 2020 at 3:27 PM Pierre-Elliott Bécue wrote:
>> I'd rather try to solve the issue in a more sensible way : lower
>> the number of expected GPG signatures to 0 temporarily, and ask
>> for two or three advocacies from DDs.

Paul> This seems like the most natural solution to the problem of
Paul> COVID mentioned thus far.

How do you feel about the idea of short-term expirations on signatures
proposed in the previous message on the list?

Re: Potential Summary: Keysigning in times of COVID-19

[Ángel]

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



signature.asc
Description: This is a digitally signed message part

Re: Keysigning in times of COVID-19

[Paul Wise]

On Wed, Aug 12, 2020 at 3:27 PM Pierre-Elliott Bécue wrote:

> I'd rather try to solve the issue in a more sensible way : lower the
> number of expected GPG signatures to 0 temporarily, and ask for two or
> three advocacies from DDs.

This seems like the most natural solution to the problem of COVID
mentioned thus far.

> We'd lose a bit of ID verification security for the DM status, but we
> could regain this security when the DM applies to become a DD, as they'd
> have to reach out to other developers and get their key signed.

We could also ask them to get signatures once the COVID situation in
their area allows them to do that.

> This wouldn't solve the broader issue that can arise when one lives in a
> place with no close DD and wants to become a DD themselves.

Given the "problems" that are being discussed on another thread in
another location, I think there is an obvious solution to solve both
issues at the same time, once the COVID situation allows it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Keysigning in times of COVID-19

[Pierre-Elliott Bécue]

Le jeudi 06 août 2020 à 17:54:21+0200, Enrico Zini a écrit :
> 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.
> 
> For example, speaking of myself only, if my goal is to raise the cost of
> impersonation or sock puppet identities, then probably signing someone's
> key after having worked with them online for a significant time, would
> require a much higher cost than showing up at a keysigning party with a
> fake ID good enough to fool me.
> 
> Others may have other policies, and are likely to be acceptable.
> 
> 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.
> 
> I think the world has changed enough in the last months that currently
> perceived project expectations about key signing are getting out of
> alignment with practical realities, and it might be time to explore
> other options.
> 
> I do not intend to ask people to break their sensible signing policies
> so that people can get into Debian. I'm interested instead in exploring
> what signing policies people may have, or may be considering, that have
> been staying out of our narrative because we've always been having a
> specific standard one that worked.
> 
> 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?

IMHO, the issue with lowering keysigning policy is that these signatures
will be as valid as any other for later DD application, while we
probably don't want to lower our expectations for other status
applications than DM.

I'd rather try to solve the issue in a more sensible way : lower the
number of expected GPG signatures to 0 temporarily, and ask for two or
three advocacies from DDs.

We'd lose a bit of ID verification security for the DM status, but we
could regain this security when the DM applies to become a DD, as they'd
have to reach out to other developers and get their key signed.

This wouldn't solve the broader issue that can arise when one lives in a
place with no close DD and wants to become a DD themselves.

But it'd be a start.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Re: Potential Summary: Keysigning in times of COVID-19

[Jonas Smedegaard]

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

signature.asc
Description: signature

Re: Potential Summary: Keysigning in times of COVID-19

[Sam Hartman]

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.
  


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Jonathan McDowell]

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


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Adrian Bunk]

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 0xDEADBEEF 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 0xDEADBEEF 
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

Re: Keysigning in times of COVID-19

[Giovanni Mascellani]

Il 07/08/20 11:34, Holger Levsen ha scritto:
> this is factually incorrect: while there are DDs who don't go by their
> government backed identity indeed, DAM or ftp master (dont rememeber which)
> do know their government identity.

Ah, didn't know that. Still, this is not represented on PGP keys, and
the rest of my email holds anyway.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Re: Keysigning in times of COVID-19

[Holger Levsen]

On Sun, Aug 09, 2020 at 08:51:30AM -0400, Sam Hartman wrote:
> It sounds like you are hearing me as disagreeing with *you* and not with
> some combination of your ideas and how they are presented.
> I'd like to offer to sit down virtually and work through this.
> I don't want to come across as hostile, and I hope that we would both
> choose to avoid frustration or worse building between us.
> 
> However my experience is that mailing lists are not the best media for
> working through things when perceptions of hostility get involved.
> If you'd be open I propose that we get together on IRC or phone (with a
> third party if that would make you feel more comfortable) and see if we
> can work to a place where you feel valued, even if we don't get to a
> place where we are in agreement on everything.
> After I'd be happy to come back to the list, express any regrets and
> summarize what I've learned about how to approach this situation without
> creating negative feelings.
> 
> If you are open to this, let's coordinate a time off-list.

Sam, you accused Olek of derailing the situation, which (AFAICS) he disagrees
with, and now you are "offering" to solve this problem by Olek investing 
more time to solve a problem that doesnt also in my book doesnt exist.

btw, I could also say you Sam are derailing Enricos thread as well, voila.

Olek replied how/when keysigning is important to them, with a concrete use-case
(sponsoring uploads), which IMO is a very fine use case of key signing
and I am puzzled about your response of cornering into counceling his behaviour.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Sam Hartman]

> "Olek" == Olek Wojnar  writes:

Olek>Sam, I do not appreciate your aspersions and I think your

Hi.
It sounds like you are hearing me as disagreeing with *you* and not with
some combination of your ideas and how they are presented.
I'd like to offer to sit down virtually and work through this.
I don't want to come across as hostile, and I hope that we would both
choose to avoid frustration or worse building between us.

However my experience is that mailing lists are not the best media for
working through things when perceptions of hostility get involved.
If you'd be open I propose that we get together on IRC or phone (with a
third party if that would make you feel more comfortable) and see if we
can work to a place where you feel valued, even if we don't get to a
place where we are in agreement on everything.
After I'd be happy to come back to the list, express any regrets and
summarize what I've learned about how to approach this situation without
creating negative feelings.

If you are open to this, let's coordinate a time off-list.

Re: Keysigning in times of COVID-19

[Gunnar Wolf]

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 0xDEADBEEF 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.

Re: Keysigning in times of COVID-19

[Gunnar Wolf]

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


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Felix Lechner]

Hi Olek,

On Sat, Aug 8, 2020 at 6:36 PM Olek Wojnar  wrote:
>
> You are attributing motivations to me that I do not have.

More significantly, you are not responsible for "our tendency to suck
every discussion into such a long-term thing that it immobilizes us."
Sam is right with his general observation, but the issue is social. We
need fewer hurt feelings and more trust in each other. Debian is more
than its parts.

At the end of the day, we all want the same thing. Let's give the
world a great operating system!

Kind regards
Felix Lechner

Re: Keysigning in times of COVID-19

[Eldon Koyle]

On Sat, Aug 8, 2020 at 5:04 PM Sam Hartman  wrote:

> Until you have a concrete suggestion, you're derailing the discussion.
> Enrico and a number of people sound like they would like a way forward
> that works for people trying to become DMs today.
> When I hear things like "eventually have a GR," that's on an entirely
> different scope than they are asking about.


Would it be a reasonable compromise to start a new thread rather than
just quashing any deeper discussion?

-- 
Eldon

Re: Keysigning in times of COVID-19

[Olek Wojnar]

Sam,

I do not appreciate your aspersions and I think your hostile attitude is
completely uncalled for. I don't know why me sharing my thoughts on this
subject has triggered you into lashing out.

On Sat, Aug 8, 2020, 19:04 Sam Hartman  wrote:

>
> Sometimes that is necessary; some ideas need to be stopped.
>
> I disagree that processing DMs today is such an idea.
>

You are attributing motivations to me that I do not have. Allow me to
repeat myself, again: I see the question of real-life verification as
central to the issue that was raised. I'm not the first to bring it up. I
do not appreciate your dismissive attitude, it comes across as quite
condescending. Last I checked, everyone in Debian was free to share their
opinions, especially in response to a call for opinions.

To connect the dots more obviously, if there is a consensus that a
contributor's online identity and reputation is sufficient for Debian's
purposes then that answers the original question and clarifies the
project's position on the subject.

I have no intention of continuing pointless quibbling. I have made my
point. If other people agree, great. If they disagree, that's fine too.
Let's just try to be civil and professional, ok?

Re: Keysigning in times of COVID-19

[Sam Hartman]

> "Olek" == Olek Wojnar  writes:


>  TL;DR: While there may be improvements to be found in a
> completely different approach to identity, let us not let the
> scope of the discussion broaden that far, so we can make
> progress today.

Olek>I respectful disagree on this point. This conversation
Olek> started with a question about how to verify identity without
Olek> in-person interaction.  The reason a number of people have
Olek> seemingly broadened the scope (from my perspective, I clearly
Olek> don't know people's actual motivations) is because that is the
Olek> deeper question behind the original query.

Until you have a concrete suggestion, you're derailing the discussion.
Enrico and a number of people sound like they would like a way forward
that works for people trying to become DMs today.
When I hear things like "eventually have a GR," that's on an entirely
different scope than they are asking about.

It's possible no short-term solutions will emerge.
And I don't mind people exploring longer-term things.
What I mind a great deal is our tendency to suck every discussion into
such a long-term thing that it immobilizes us.
You are adding stop energy: you've broadened the scope to a question
that you then say you cannot answer.

Sometimes that is necessary; some ideas need to be stopped.

I disagree that processing DMs today is such an idea.

Re: Keysigning in times of COVID-19

[Olek Wojnar]

Hi Sam,

On Sat, Aug 8, 2020, 11:46 Sam Hartman  wrote:

>
> TL;DR: While there may be improvements to be found in a completely
> different approach to identity, let us not let the scope of the
> discussion broaden that far, so we can make progress today.
>

I respectful disagree on this point. This conversation started with a
question about how to verify identity without in-person interaction. The
reason a number of people have seemingly broadened the scope (from my
perspective, I clearly don't know people's actual motivations) is because
that is the deeper question behind the original query.

> "Olek" == Olek Wojnar  writes:
>
> Olek> Thanks to some great tools, it's fairly easy to
> Olek> verify that they do indeed control the email addresses tied to
> Olek> their key. That's what I care about at that point in time.
>
> For me, that's not nearly enough.
> If all you want to do is verify that a particular point in time, an
> email address belongs to a key, set up a service to do that.
>

I was referring to the caff package.

When I sign a key I am signing a certification that I believe
> 1) the key and
> 2) the real world identity
>
> correspond to the digital identity in the FLOSS community represented by
> the claimed email address.
>

That is how I have always done it as well but this conversation is making
me rethink the *why* of that process.

I don't want to throw out what we have without a viable suggestion that
> the project can get behind.
>

Agreed.

So, let's focus this thread on key signing and how to adapt that because
> it's what we have today and because we're looking for some short-term
> answers.
> If you want to start a different thread proposing to revamp how we think
> about identity, go for it.
>

Again, I disagree that these are distinct topics. I think they are
intrinsically linked.

There have been some good points so far about the value of having a
real-world identity connected to your Debian identity for reasons of
accountability and liability. There have also been good points about
personal privacy. (Dissident Test, anyone?)

I was just recently speaking with a prospective first-time contributor who
was very excited about being involved in the project but was not
comfortable sharing their real life identity. Do we turn people like that
away or welcome their contributions into the project once we have validated
their reliability and trustworthiness *in the scope of the Debian Project*?
Do we absolutely *have* to have a real life identity connected to someone
to sign their key? Or to accept a patch? Or a packaging job? Or permissions
as a DM?

I'm not advocating a position since I'm not 100% sure what the answer
should be. But I think that these are important questions to ask ourselves
and an important conversation to have. Perhaps this will eventually lead to
a GR, or perhaps we'll develop a consensus here. But we absolutely need to
be having this conversation and considering all points of view and
repercussions.

-Olek

>

Re: Keysigning in times of COVID-19

[Sam Hartman]

TL;DR: While there may be improvements to be found in a completely
different approach to identity, let us not let the scope of the
discussion broaden that far, so we can make progress today.

> "Olek" == Olek Wojnar  writes:


Olek>  TL;DR: I think without some link back to real world
Olek> identity, we open ourselves up to attacks where people build
Olek> trust only to betray us.

Olek>I agree with you that this is a potentially-serious
Olek> problem. However, I'm not sure that keysigning is the right
Olek> place to address it. I've seen a number of comments, including
Olek> yours, seemingly conflate the trust we place in the validity
Olek> of a cryptographic key and the trust we place in someone
Olek> during the NM process.

To some extent I've been sloppy because it's the end result I care about
 not where in the process particular steps happen.

I'm happy to dig into my thoughts on the breakdown though.

Olek> I think it is important to distinguish
Olek> between the two.  So, I don't really care (much) how
Olek> technically competent or hard-working someone is when I sign
Olek> their key.

Agreed.
I care to some extent how good of a job I think they will do in key
management, and some of that is technical.

Olek> Thanks to some great tools, it's fairly easy to
Olek> verify that they do indeed control the email addresses tied to
Olek> their key. That's what I care about at that point in time.

For me, that's not nearly enough.
If all you want to do is verify that a particular point in time, an
email address belongs to a key, set up a service to do that.
That would be a valuable service for many purposes, but don't waste my
time signing stuff if that's all you want.
Such a service would have an implicitly (or explicitly if it were
documented) different certification process than my signatures.
I argue Debian should not trust such a service for the identity
verification part of our membership process.

When I sign a key I am signing a certification that I believe
1) the key and
2) the real world identity

correspond to the digital identity in the FLOSS community represented by
the claimed email address.

That is a statement that is deeper than simply that the email adress
corresponds to the key.


Olek> Now, if they want me to sponsor them in the NM process, that's
Olek> when I am going to take a much closer look at their work and
Olek> their attitude and determine if we should grant them the level
Olek> of trust that goes with completing that process.

Agreed.

Olek> That is also
Olek> where I humbly submit we should have some level of identity
Olek> verification. I'm not sure what that should look like but the
Olek> point is where it should take place. If we previously verified
Olek> someone's identity and subsequently banned them from the
Olek> project, the NM process seems like the logical place to ensure
Olek> that such a person is not able to slip back into
Olek> Debian. Centralized and standardized is much easier in a
Olek> process administered by a few people (NM) than in a
Olek> distributed process with substantial variability and no means
Olek> of reliable QA (random keysigning party).  -Olek

It's hard to evaluate such a suggestion until you do know what such a
process looks like.
I think that what we have today  by caring more about identity than
simply keys belonging to email addresses works reasonably well.
It may be that some identity verification process in NM works even
better.
I don't want to throw out what we have without a viable suggestion that
the project can get behind.

As an example, while copying government IDs and checking against some
central service, possibly also using one of those identity verification
services that looks at credit information etc, might (for many people in
the US and Europe at least) be more effective than what we do, I have
great confidence that would not be politically acceptable to the
project.
So, let's focus this thread on key signing and how to adapt that because
it's what we have today and because we're looking for some short-term
answers.
If you want to start a different thread proposing to revamp how we think
about identity, go for it.  For me at least you'll need a concrete
suggestion before I can approach that discussion.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Olek Wojnar]

Hi Sam,

On Fri, Aug 7, 2020 at 3:39 PM Sam Hartman  wrote:

>
> TL;DR: I think without some link back to real world identity, we open
> ourselves up to attacks where people build trust only to betray us.
>

I agree with you that this is a potentially-serious problem. However, I'm
not sure that keysigning is the right place to address it. I've seen a
number of comments, including yours, seemingly conflate the trust we place
in the validity of a cryptographic key and the trust we place in someone
during the NM process. I think it is important to distinguish between the
two.

So, I don't really care (much) how technically competent or hard-working
someone is when I sign their key. Thanks to some great tools, it's fairly
easy to verify that they do indeed control the email addresses tied to
their key. That's what I care about at that point in time.

Now, if they want me to sponsor them in the NM process, that's when I am
going to take a much closer look at their work and their attitude and
determine if we should grant them the level of trust that goes with
completing that process. That is also where I humbly submit we should have
some level of identity verification. I'm not sure what that should look
like but the point is where it should take place. If we previously verified
someone's identity and subsequently banned them from the project, the NM
process seems like the logical place to ensure that such a person is not
able to slip back into Debian. Centralized and standardized is much easier
in a process administered by a few people (NM) than in a distributed
process with substantial variability and no means of reliable QA (random
keysigning party).

-Olek

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Sam Hartman (2020-08-07 23:29:23)
> > "Jonas" == Jonas Smedegaard  writes:
> 
> Jonas> I feel that you are somewhat quoting me out of context:
> 
> Jonas> For the record, I do *not* find "several months of [remote]
> Jonas> collaboration" adequate for trusting an identity.  I simply
> Jonas> repeated that criterium from the previous poster - the point
> Jonas> I wanted to make was not to confirm the _concrete_ presented
> Jonas> criterium, but instead that whatever criteria was adequate
> Jonas> first time you met someone should be adequate the next time
> Jonas> as well.
> 
> I'm sorry.
> I was aware I was doing this and suspected that you might not agree with
> the original criteria.  I failed to make that clear in my message.
> I wasn't sure where to jump in and apparently chose poorly.
> 
> Thanks for calling me on this.

I was not offended, just felt the need to clarify when you "put it out 
on display".

Thanks,

 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Sam Hartman]

> "Jonas" == Jonas Smedegaard  writes:

Jonas> I feel that you are somewhat quoting me out of context:

Jonas> For the record, I do *not* find "several months of [remote]
Jonas> collaboration" adequate for trusting an identity.  I simply
Jonas> repeated that criterium from the previous poster - the point
Jonas> I wanted to make was not to confirm the _concrete_ presented
Jonas> criterium, but instead that whatever criteria was adequate
Jonas> first time you met someone should be adequate the next time
Jonas> as well.

I'm sorry.
I was aware I was doing this and suspected that you might not agree with
the original criteria.  I failed to make that clear in my message.
I wasn't sure where to jump in and apparently chose poorly.

Thanks for calling me on this.

--Sam

Re: Keysigning in times of COVID-19

[Cindy Sue Causey]

On 8/7/20, Sam Hartman  wrote:
>
> TL;DR: I think without some link back to real world identity, we open
> ourselves up to attacks where people build trust only to betray us.


Hi, Everyone.. I've tried to follow some of this conversation but keep
getting distracted. I haven't known where to chime in with Real World
experience, either.

My interest in this is that I *have* been impersonated online. It
matters because I'm trying to work my way through a package that was
abandoned, apparently because so many things have been being upgraded
and refined within Debian the last few years..

So, in my case, what had happened was

Perps, a very local group that operates across the United States,
created a Twitter account [0] using.. my full name.. my avatar.. my
personal images including that large header image.. AND my complete
textual bio such as it was at that moment in time.

Twitter took that fake account down so fast when I contacted them that
I didn't get a printscreen as some kind of proof. The original
homepage for it is still out there gathering cyber dust.

So, you know... Full blown, malicious impersonation is very real for
some of us out here. Only reason I ever found out was because Google
Alerts brought my own name back to my inbox one day.

As another instance showing Debian does need to keep things in check,
I just tripped over something from last year. It appears to
potentially still be a possible active case so I'm not going to share
that much of the details right now.

The guy's no longer around but someone posted something cryptic on
his social networking.. after he was gone. It's possible he used
something like Hootsuite or something to leave a timed post set for
the Future. Only time will tell on that..

He was a techie.. possibly building himself a notable reputation
around the Internet. He followed very few people.. but he picked at
least one *I* know from online interactions..

Am still in the process of trying to figure out who's who and doing
what with the remnants of his presence left on the Internet.
Meanwhile, I swear I've been back to Debian's Developers at least
once.. or maybe more. I don't know if I'm reading something wrong...
or if it's my system glitching at just the wrong time.. or what.

The disconnect that repeatedly landed me at a Debian email address was
happening somewhere between his old profile, his followers, and who he
followed. I wasn't copying an email address when the Debian one kept
appearing (at least 4 or 5 times). I haven't proven to myself quite
how that happened, yet, but I do have one clue that needs followed up
(in my brain, grin).

Date of last activity for some bits of that other case goes back to
just before that Twitter account was created in my full likeness. Only
difference in my own case was the perps gave their physical location
as West Virginia instead of Georgia.

Oh, and my account was NOT hacked. It was instead replicated visually
then placed under a completely new account name... that had my very
real name attached.

I'm signing off here for now. Too much going in too many directions. I
will most certainly be trying to find the right way to bring it up
with full details if that other case really, in fact, seems to have
some kind of 100% reproducible identity weirdness leading to Debian's
front door

Hugging you all for all the hard work you do. I wouldn't be able to do
any of what I do without this kind of project being available...

Cindy :)

[0] Suspended Twitter account placeholder for studebarke (I'm "Studebaker")
https://twitter.com/studebarke

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Sam Hartman (2020-08-07 21:14:10)
> 
> TL;DR: I think without some link back to real world identity, we open
> ourselves up to attacks where people build trust only to betray us.
> 
> > "Jonas" == Jonas Smedegaard  writes:
> 
> Jonas> Quoting Gerardo Ballabio (2020-08-07 10:34:20)
> >> Johannes Schauer wrote:
> Jonas> If ok for first round of several months collaboration was
> Jonas> conducted without ties to governmental papers, then
> Jonas> continuation should as well.
> 
> Jonas> If you are not confident that the person is the same from
> Jonas> coding style, text-chatting style, mimics in videochat etc.,
> Jonas> then apply same requirement as you did for first round: Trust
> Jonas> only after several months of collaboration tied to the _new_
> Jonas> key.
> 
> Jonas, first thanks for describing your rule about interacting with
> someone enough that you'd recognize them later.
> 
> I think that makes sense.  I'm uncomfortable though with the idea that
> someone could get their key signed by doing good work, lose the key and
> get another key signed later by again doing good work.
> That opens up attacks that I care about in our model of trust.

I agree.

I feel that you are somewhat quoting me out of context:

For the record, I do *not* find "several months of [remote] 
collaboration" adequate for trusting an identity.  I simply repeated 
that criterium from the previous poster - the point I wanted to make was 
not to confirm the _concrete_ presented criterium, but instead that 
whatever criteria was adequate first time you met someone should be 
adequate the next time as well.

Yes, we should try be aware of the risk of betrayal - but that can 
equally well happen at first encounter (I don't know everyone in Debian 
so some could fool me arguing they were "new").  And it can happen with 
a faked name and faked passport (I expect it to be *cheap* to fake a 
passport when not validating by looking up a central database).


 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Sam Hartman]

TL;DR: I think without some link back to real world identity, we open
ourselves up to attacks where people build trust only to betray us.

> "Jonas" == Jonas Smedegaard  writes:

Jonas> Quoting Gerardo Ballabio (2020-08-07 10:34:20)
>> Johannes Schauer wrote:
Jonas> If ok for first round of several months collaboration was
Jonas> conducted without ties to governmental papers, then
Jonas> continuation should as well.

Jonas> If you are not confident that the person is the same from
Jonas> coding style, text-chatting style, mimics in videochat etc.,
Jonas> then apply same requirement as you did for first round: Trust
Jonas> only after several months of collaboration tied to the _new_
Jonas> key.

Jonas, first thanks for describing your rule about interacting with
someone enough that you'd recognize them later.

I think that makes sense.  I'm uncomfortable though with the idea that
someone could get their key signed by doing good work, lose the key and
get another key signed later by again doing good work.
That opens up attacks that I care about in our model of trust.

The threat I care about that I hope key signing will help protect us
from is the threat of someone intentionally decreasing the integrity of
Debian.  That is, someone includes malicious code (or similarly
undermines our reputation).

In my mind, we want to require

1) That someone builds up a significant positive reputation

and

2) That  it would be costly for them to burn that reputation to maount
an attack.

In this model the advantage of trying to tie a key back to a real-world
identity is that we only get one of those.
No matter how much good work I do in the future, I cannot escape a
betrayal of trust if we tie it back to Sam Hartman.

But if we don't tie it back, let's say I do a year's worth of good work
as DebianDude and eventually get my key signed.
I can burn that reputation for an attack, having lost a year, but not
lost my future possibility of spending another year and getting trusted
again (possibly for another attack).

An attacker might be much more willing to burn their DebianDude
reputation than their Sam Hartman reputation.


Now, that real world identity might not even need to be a real name.
If you're going to recognize the person, know that you've already signed
their key, that's probably enough.
You can think think about whether this is a legitimate and harmless
identifier change or whether this is an attempt to cause harm.  But you
can consider all the identities you've known and link it back to the
person.
For me, that linking is key to key signing being valuable.


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Ulrike Uhlig]

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

Re: Keysigning in times of COVID-19

[Adrian Bunk]

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

Re: Keysigning in times of COVID-19

[Alberto Garcia]

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

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Alexandre Viau (2020-08-07 05:44:34)
> On 2020-08-06 11:54 a.m., 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?
> 
> Hello Enrico :)
> 
> Thank you for bringing this up.
> 
> On 2020-08-06 1:26 p.m., Johannes Schauer wrote:
> > So in my opinion (and please correct my assumptions if they are
> > wrong), an acceptable key signing policy would also be one, where a
> > prospective DM has shown over several months to produce work that is
> > always signed with the same key and maybe even communicated (for
> > example via email, maybe even encrypted) using that GPG key.
> 
> This makes sense.
> 
> Whoever advocated for me to become a DD advocated for the person that
> was signing patches with E301 54F5 429F FBB9 B22E 49C2 DA82 830E 3CCC
> 3A3A. They had never met me. It didn't matter. My key was added to the
> keyring because whoever was signing emails and uploaded with that key
> seemed to care enough about Debian and seemed to produce work that is
> good enough to be let in the archive.
> 
> There were also DD signatures on my key at the time, but none of them
> had worked with me. They only loosely verified that the awkward guy at
> the coffee shop received or intercepted emails sent at
> alexan...@alexandreviau.net.
> 
> I have recently advocated for somebody to become DM. I have some 
> indirect connection with him in the real world, but I have never met 
> him in person. Having his key signed is blocking his NM DM process.
> 
> I am sure that I "know" this guy. He signs all of his messages with 
> the same PGP key. He signs all of his patches with the same PGP key. 
> He cares about Debian. He asks good questions. If we meet at DebConf, 
> I'll be able to tell that its him. I'll point him to you guys so that 
> you know who he is.
> 
> We will organize a video call, just to meet outside of emails, but I 
> won't verify his ID, and I will sign his key so that we can move 
> forward.
> 
> Feel free to attribute whatever value that you want to that signature. 
> I think that given my history with that person it holds much more 
> values than the 2-minutes KSP ones.

Advocacy and autenticity are separate things.

I can vouch for the person in control of E301 54F5 429F FBB9 B22E 49C2 
DA82 830E 3CCC 3A3A regarding quality of Debian work and understanding 
of Debian spirit, when I have seen some work and some personal 
reflections signed by that identifier.

I can autenticate the person in control of E301 54F5 429F FBB9 B22E 49C2 
DA82 830E 3CCC 3A3A when I somehow gain confidence of who that person is 
- maybe through signed work and reflections, maybe through governmental 
papers, maybe through physical/audio/video presence - more likely 
through a combination of most possible of those.

It is important for Debian that all members meat a certain level of 
competences and concensus of spirit (on Debian matters only).

...but it is also important for Debian that members each are represented 
through a single identifier - not multiple.

If only looking at work and reflections, I'd argue that it would be much 
much harder to notice if E301 54F5 429F FBB9 B22E 49C2 DA82 830E 3CCC 
3A3A was controlled not by an independent person but e.g. me.


 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Didier 'OdyX' Raboud]

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 ?

signature.asc
Description: This is a digitally signed message part.

Re: Keysigning in times of COVID-19

[Holger Levsen]

On Thu, Aug 06, 2020 at 08:44:57PM +0200, Giovanni Mascellani wrote:
> Not to mention that as far as I know there are already DDs whose key
> identity does not correspond to any government-given identity. So we
> already acknowledge that we don't really care about what is your "legal"
> name. 

this is factually incorrect: while there are DDs who don't go by their
government backed identity indeed, DAM or ftp master (dont rememeber which)
do know their government identity.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Gerardo Ballabio (2020-08-07 10:34:20)
> Johannes Schauer wrote:
> > So in my opinion (and please correct my assumptions if they are wrong), an 
> > acceptable key signing policy would also be one, where a prospective DM has 
> > shown over several months to produce work that is always signed with the 
> > same key and maybe even communicated (for example via email, maybe even 
> > encrypted) using that GPG key.
> 
> I agree that it would be ok to sign that key.
> 
> However, suppose that the key gets lost or compromised.
> Then the prospective DM creates a new key and asks you to sign it.
> How would you verify that the person that shows up with the new key is
> the same person that you have been working with?
> 
> I can't think of an answer that doesn't require connecting the person
> to a verified personal identity (that may or may not be a
> government-certified name).

If ok for first round of several months collaboration was conducted 
without ties to governmental papers, then continuation should as well.

If you are not confident that the person is the same from coding style, 
text-chatting style, mimics in videochat etc., then apply same 
requirement as you did for first round: Trust only after several months 
of collaboration tied to the _new_ key.


 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Gerardo Ballabio]

Johannes Schauer wrote:
> So in my opinion (and please correct my assumptions if they are wrong), an 
> acceptable key signing policy would also be one, where a prospective DM has 
> shown over several months to produce work that is always signed with the same 
> key and maybe even communicated (for example via email, maybe even encrypted) 
> using that GPG key.

I agree that it would be ok to sign that key.

However, suppose that the key gets lost or compromised.
Then the prospective DM creates a new key and asks you to sign it.
How would you verify that the person that shows up with the new key is
the same person that you have been working with?

I can't think of an answer that doesn't require connecting the person
to a verified personal identity (that may or may not be a
government-certified name).

Gerardo

Re: Keysigning in times of COVID-19

[Alexandre Viau]

On 2020-08-06 11:54 a.m., 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?

Hello Enrico :)

Thank you for bringing this up.

On 2020-08-06 1:26 p.m., Johannes Schauer wrote:
> So in my opinion (and please correct my assumptions if they are
> wrong), an acceptable key signing policy would also be one, where a
> prospective DM has shown over several months to produce work that is
> always signed with the same key and maybe even communicated (for
> example via email, maybe even encrypted) using that GPG key.

This makes sense.

Whoever advocated for me to become a DD advocated for the person that
was signing patches with E301 54F5 429F FBB9 B22E 49C2 DA82 830E 3CCC
3A3A. They had never met me. It didn't matter. My key was added to the
keyring because whoever was signing emails and uploaded with that key
seemed to care enough about Debian and seemed to produce work that is
good enough to be let in the archive.

There were also DD signatures on my key at the time, but none of them
had worked with me. They only loosely verified that the awkward guy at
the coffee shop received or intercepted emails sent at
alexan...@alexandreviau.net.

I have recently advocated for somebody to become DM. I have some
indirect connection with him in the real world, but I have never met him
in person. Having his key signed is blocking his NM DM process.

I am sure that I "know" this guy. He signs all of his messages with the
same PGP key. He signs all of his patches with the same PGP key. He
cares about Debian. He asks good questions. If we meet at DebConf, I'll
be able to tell that its him. I'll point him to you guys so that you
know who he is.

We will organize a video call, just to meet outside of emails, but I
won't verify his ID, and I will sign his key so that we can move forward.

Feel free to attribute whatever value that you want to that signature. I
think that given my history with that person it holds much more values
than the 2-minutes KSP ones.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Re: Keysigning in times of COVID-19

[Héctor Orón Martínez]

Hello,

El dj., 6 d’ag. 2020, 18:08, Enrico Zini  va
escriure:

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

  - you know that person in the real world, or at least you have verified
and trusted their real world credentials somehow (*).

(*) Verification of real world credentials could be done by different
means, probably simplest would be having a video call (that would be fine
for me).

Re: Keysigning in times of COVID-19

[Christian Kastner]

On 2020-08-06 17:54, 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?

As food for thought, there was a longish thread "Why are in-person
meetings required for the debian keyring?" on -project a few years ago
with good inputs both for and against.

https://lists.debian.org/debian-project/2015/02/msg00017.html

Re: Keysigning in times of COVID-19

[Giovanni Mascellani]

Hi,

Il 06/08/20 19:26, Johannes Schauer ha scritto:
> What added value does the connection to a government ID give to Debian?

And even if we assumed that it is for some reason useful to link each DD
to a "government-verified" identity[1], what we actually verify
(basically, the names) is very little. Normal practice, at least in the
countries I've experience with, is to collect names, date and place of
birth, current home address, possibly a unique government-given
identification number (or at least the identification number of the
document).

 [1] For example, to consider them legally responsible if they do
something bad, and some user tries to seek for damage compensation from
the project.

Having just the name of someone is rather useless. Any person named
"Giovanni Mascellani" can legitimately go to a keysigning party and get
signatures on their key, which is as much linked to me as my actual key
is. So what is the benefit of my key being associated to "Giovanni
Mascellani" if it is not clear which "Giovanni Mascellani" that is?

Not to mention that as far as I know there are already DDs whose key
identity does not correspond to any government-given identity. So we
already acknowledge that we don't really care about what is your "legal"
name. We only care that there are enough people in the community who
consider your key identity a reasonable way to identify you. This
identification principle does not require to meet in person and use
government-issued documents to identify each other (although that
remains a totally legitimate way to go, for those who recognize it).

(also, one can produce PGP signatures stating that they "didn't make any
check of the other person's identity", which as far as I know are
accepted by GPG, and by Debian for verifying DDs, as much as any other
signature; I don't really understand what's the point of such signature
level, although I emit it interpreting it as "I made a very light check
of the other person's identity")

My two cents, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Re: Keysigning in times of COVID-19

[Jonas Smedegaard]

Quoting Enrico Zini (2020-08-06 17:54:21)
[...]

> 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.
> 
> For example, speaking of myself only, if my goal is to raise the cost 
> of impersonation or sock puppet identities, then probably signing 
> someone's key after having worked with them online for a significant 
> time, would require a much higher cost than showing up at a keysigning 
> party with a fake ID good enough to fool me.

[...]

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

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

I've practiced my rule mostly with in-person meetings - also because I 
enjoy meeting people face to face.  But a few times I have felt 
comfortable that I "knew" someone after working for some time with them 
online, without having had the opportunity to meet physically.

It feels reliable to me to trust a passport, and it feels unreliable to 
me to skip it.  But I find it helpful to try challenge that feeling and 
try peel off what is simply habit.


Thanks for bringing this up, Enrico,

 - Jonas

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

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

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Johannes Schauer]

Hi Enrico,

thanks for bringing this up.

Quoting Enrico Zini (2020-08-06 17:54:21)
> 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'm currently in the situation of sponsoring a very skilled prospective new DM
with a couple of packages. My mentee is signing all their git commits and git
tags as well as their emails to me with the same GPG key. This has now been
going on for a few months. So I'm in the situation, that I know that somebody
owning a certain private key is either (correct me if I'm wrong):

 - doing a lot of good work
 - being impersonated by an evil third party that always intercepts their
   contributions to Debian (git commits to salsa) as well as their (encrypted!)
   emails to me and replaces the signature with their own

My question to you guys is: how valuable is it, that I (or anybody else) is
meeting the individual owning this key in person and indeed verifies (how
skilled are *you* in spotting a counterfeit ID?) that a nation state thinks
that the person of such name does really exist.

What added value does the connection to a government ID give to Debian?

Why would it be wrong of me to sign the key of this person? No matter who is
behind that key: the person with that key has shown to produce great
contributions for a couple of months *or* there is a really dedicated evil
person trying some scheme over a really long period of time with me. If the
latter is the case, would a person with that much commitment not also be able
to fool me with a fake national ID?

So in my opinion (and please correct my assumptions if they are wrong), an
acceptable key signing policy would also be one, where a prospective DM has
shown over several months to produce work that is always signed with the same
key and maybe even communicated (for example via email, maybe even encrypted)
using that GPG key.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Keysigning in times of COVID-19

[Felix Lechner]

Hi Enrico,

On Thu, Aug 6, 2020 at 9:15 AM Enrico Zini  wrote:
>
> What do you think could be alternative key signing policies
> ... that would not require ... meeting face to face?

Perhaps a video meeting on Jitsi [1] is acceptable? People could
present their IDs to the camera. Maybe the certification level in GPG
should be casual ('2') for such interactions.

Please note that our instructions may need to be updated. They state:
"You should never sign a key for somebody else you haven't met
personally." [2]

[1] https://jitsi.debian.social/
[2] https://www.debian.org/events/keysigning

Thanks for taking the initiative on such an important matter.

Kind regards
Felix Lechner

Re: Keysigning in times of COVID-19

[Roberto C . Sánchez]

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?
> 
What about an added dimension that may (or may not) affect the concept
of "alternative key signing policies"?

Perhaps instead of requiring "a valid DD signature" as the basis for
"important" project actions (e.g., uploading to the archive), we should
consider rather "degree of trust associated with a collection of one or
more signatures".

So, then a key not signed by any DD (directly or indirectly) might carry
a trust value of 0.  A key directly signed by 5 DDs, each of whose keys
are also directly signed by 5 other DDs, might have a trust value of 25
(or 5^2).  If the required trust value for an upload to the unstable
suite of the archive required a trust of 15, then the first key (trust
0) would not be able to upload while the second key (trust 25) would.
If someone only had a trust level of 7, they would need to find someone
(or more than one someone) to additionally sign an upload to bring the
aggregate trust level above 15.

The trust calculation may also account for the degree of connection.
E.g., the 5 DD x 5 DD example above might instead be calculated as 5 +
(5 x 1/2)^2 = 11.25, so that unique second degree signatures count half
as much as unique first degree signatures.

Of course, the concept of requiring multiple signatures does not work
for things like voting, but the trust concept could still be applied.
In effect, our current model requires a trust level of 1 on a GPG key in
order to be considered able to cast a valid vote.  This is in addition
to the requirement of having passed through the various qualifications
to be a DD and be accepted by the project.

In any event, it is just a random idea that I had.  It is not clear if
such an approach is even feasible or desirable.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Keysigning in times of COVID-19

[Enrico Zini]

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.

For example, speaking of myself only, if my goal is to raise the cost of
impersonation or sock puppet identities, then probably signing someone's
key after having worked with them online for a significant time, would
require a much higher cost than showing up at a keysigning party with a
fake ID good enough to fool me.

Others may have other policies, and are likely to be acceptable.

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.

I think the world has changed enough in the last months that currently
perceived project expectations about key signing are getting out of
alignment with practical realities, and it might be time to explore
other options.

I do not intend to ask people to break their sensible signing policies
so that people can get into Debian. I'm interested instead in exploring
what signing policies people may have, or may be considering, that have
been staying out of our narrative because we've always been having a
specific standard one that worked.

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?


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature