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 <olek@debian.org> 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.
Attachment:
signature.asc
Description: PGP signature