incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <...@shanecurcuru.org>
Subject Re: key signing
Date Wed, 10 Oct 2012 13:40:12 GMT
Comments:

- For many people, ensuring that the human who holds a specific key is 
the same one who has been using the john@doe.foo email address and the 
johndoe@apache.org SVN/GIT account over a period of time is what is most 
important.  Less important is ensuring that that human's legal name is 
John Doe.

I.e. what is often viewed as more important is the tie between a 
person's consistent past actions and their key, rather than a tie 
between their key and the name they are legally known as in some 
jurisdiction.

Especially on the internet, it's hard to know if someone else is a dog 
or not.  But it is possible to see a consistent pattern of activity over 
time that is directly associated with an Apache ID and email addresses.

- The ASF's tie of legal identity to a committer ID and the Commonwealth 
of Massachusetts' (or other legal entities) tie of identity to a drivers 
license are very different things, both in terms of difficulty to forge, 
consequences of fraud, and purpose for being.

In most cases, forging country identity cards is a crime, and actually 
takes some work.  Forging identity on the Apache iCLA is merely a matter 
of an email address and a signature.

More importantly, country identity cards have multiple reasons for 
(attempting to be) secure and reliable.  The iCLA is primarily about 
ensuring that an IP that iCLA's signer grants to us is actually 
license-able under the AL.  While we certainly hope that our 
contributors will be well behaved, honest, and secure in their work 
here, what's fundamental for each iCLA signer is that the ASF has the 
rights to ship their contributions in our products.

- The WoT doesn't scale to normal end users.  Remember, the majority of 
them have never been on the dev@ list - they just want to run our 
software in their enterprise.  I dunno what to do about that, but it 
would be useful if we could at least explain what the WoT and signing 
releases does show to our users.


- Shane


On 10/10/2012 7:20 AM, Benson Margulies wrote:
> On Wed, Oct 10, 2012 at 6:52 AM, Nick Kew <niq@apache.org> wrote:
>>
>> On 10 Oct 2012, at 11:25, Benson Margulies wrote:
>>
>>> I then feel that it's perfectly reasonable to sign a key that has two
>>> things in it: the name Noah Slater and nslater@apache.org, because if
>>> this process doesn't verify an adequate association, then no one can
>>> trust the Apache IP process, either, and which has the same signature
>>> as the one in SVN.
>>
>> The apache process is satisfied with his identity.  The apache process
>> says so by publishing the key under his name at apache.org, thus
>> establishing a certain level of trust.
>>
>> That most certainly doesn't mean I should sign the key: for me to do
>> so based on hearsay (my own trust not in his key but in the apache
>> process) just muddies the waters.
>
>
> Nick: On the one hand, how is trusting the Apache process better or
> worse than trusting the State of Massachusetts? Both offer an
> assertion of a relationship between someone and a legal identity. In
> the state of MA case, I'm matching a face to a piece of (forgeable)
> plastic. In the Apache case, I'm matching an email to the Apache
> process. In both cases, I could be the subject of a fraud: someone I
> 'know' via mailing list interactions shows up in person, shows me a
> driver's license, and satisfies me that he or she is the same person I
> 'know' online. Enter the mole.
>
> If the answer to this is that WoT is supposed to be based on some
> level of 'real personal trust' (the opposite, after a fashion, of a
> 'Facebook Friend'), then I shouldn't sign keys at signing parties,
> since there's just about no one at Apache whom I know well enough to
> meet the standard. And I feel reinforced in my original urge to write
> web pages around here that put the Apache process above the WoT.
> Ironically, I could argue that we'd be better-served with X.509 certs.
> An Apache CA could be programmed to issue a cert to each committer.
> Users would just verify the source CA, and we'd accomplish the goal of
> giving users assurance.
>
>
>>
>> The missing link is my ability to formalise my WoT level of trust
>> (whatever it might be) in the apache process by signing a key
>> labelled something like "ASF committer enrolment process" which
>> in turn automatically signs everyone's keys.  Were it not for the risk
>> of rather serious misunderstanding, I should advocate such a key.
>>
>> --
>> Nick Kew
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message