Comments:
- For many people, ensuring that the human who holds a specific key is
the same one who has been using the [email protected] email address and the
[email protected] 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 <[email protected]> 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 [email protected], 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
