From dev-return-21825-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri Mar 30 22:15:46 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DF82797A8 for ; Fri, 30 Mar 2012 22:15:46 +0000 (UTC) Received: (qmail 27087 invoked by uid 500); 30 Mar 2012 22:15:46 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 27035 invoked by uid 500); 30 Mar 2012 22:15:46 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 27027 invoked by uid 99); 30 Mar 2012 22:15:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Mar 2012 22:15:46 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.210.44 as permitted sender) Received: from [209.85.210.44] (HELO mail-pz0-f44.google.com) (209.85.210.44) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Mar 2012 22:15:39 +0000 Received: by dadz14 with SMTP id z14so18213dad.31 for ; Fri, 30 Mar 2012 15:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QhCUs1/WS9sB9Pui6BPqeYokcRq1NIQOuIReflO6kR8=; b=H5+XcYyS07u8mLeS2CpnxEfr9+DIKvLgHxcKSCP4+MN1TqgMQhtfCS6ViENJAHtUyb LGn/xKe6QjQ6/DIkz+uly+M+jK1IpYH9VQi96hsuV25FtobOpXm+LUtEqbyizZmi8fjr gS4hyi+w+GJqmAV7sqaLlSM53gulNZxrXCvkGn33JpQQtneC9+inXOGjgbgJZ+G/hrDa MosO0niaG1Wovzkh3ZRluVPufO1EHds4/ktvtdORBqxf2pi19WXhUond2chwU+PTjsN3 N4zbO+2z6ZNbZ0fWfL28nYTtVHtn5JOMXUFYbt+Y7921JamDEhyjn5mmW5iHu7v1pgTv ZUlQ== MIME-Version: 1.0 Received: by 10.68.197.164 with SMTP id iv4mr1400448pbc.11.1333145718111; Fri, 30 Mar 2012 15:15:18 -0700 (PDT) Received: by 10.68.234.168 with HTTP; Fri, 30 Mar 2012 15:15:18 -0700 (PDT) Date: Fri, 30 Mar 2012 15:15:18 -0700 Message-ID: Subject: On Key Signing (was Re: [VOTE] Apache CouchDB 1.2.0 release, fifth round) From: Randall Leeds To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 06:30, Noah Slater wrote: > My key is signed by: > 85E0E79A 2011-10-19 =C2=A0Randall Leeds > > I am actually a little confused why Randall has signed my key. He has nev= er > met me, nor has he ever confirmed my identity, nor has he any assurances > that the key he signed is mine. Randal, maybe you should come to Dublin, > and you can make up for this faux pas? Dave, you need to do the same, if > you want to link our trust circles. I would love to come to Dublin. I'd totally like to make it happen this year. For now, I'd love to talk about this in case its a good teaching moment. I'm relatively new to this and may be going about things in the wrong way. I have never met you. I may disagree that I have never confirmed your identity. Maybe I'm not sure what that actually means. Does it mean that you are called Noah Slater by some government authority? Do I care? I care that our release manager is the one signing our releases and the one calling our votes and that he owns the identity referenced by this key. I have several pieces of infrastructure and communication security (@apache.org email, repository access, IRC cloak, the web of trust with those I have met personally) that tell me this is probably the case as well as lots of online activity correlation that provides strong evidence that this is so. Therefore, I feel fairly confident stating that the actions of some person who is executing releases and signing code using this key are attributable to some Noah Slater who communicates using the associated email addresses and is an Apache CouchDB PMC member and release manager. But I think the rub is that trust and validity are different things. I do know, with 100% confidence, that the key I signed has been signing code releases. Whether it belongs to some particular Noah Slater who is *trusted* is a human call. More importantly, it's one that I did not, and perhaps should not, publicise without meeting you in person, though the reasons for this aren't totally clear. I locally trust you, but perhaps not enough to publish that trust without meeting you in person. To me, the faux pas is failing to recognise that a web of trust means that ***I do not need need to sign your key to lend weight to its trustworthiness*** because I have done so transitively by signing other, nearby keys. Some subtlety here, I think, escaped me for a time. I believe a (much more) serious faux pas would be if I had signed your key and it had contained a picture. Since I have not met you I cannot assert that you "look like ", but the assertions I have made seem relatively sound. Someone wanting to know whether a tarball they received was actually created by our release manager can trust me with that assertion (if they trust me at all). Please point out where I'm wrong, though. I think I've been publicly overly assertive, but not dangerously or recklessly so. You are mostly likely correct that I should not have signed your key, but I hope you agree with my assessment of the situation and can offer some insight as to what, exactly, I gain by meeting you in person. When I meet people in person and exchange keys, they usually ask to see my key fingerprint and check that it's the one their seeing. In other words, they verify that the key they're signing is the one I claim to own and they aren't being tricked by a MITM, but they don't actually make any other checks about who I am. They are communicating some notion of trust based on the social signals of the context of our meeting. "We met at this place, we talked about stuff, and this person seemed to be the person I associate with this key, so I 'trust' them." What does it mean to trust? It's totally human. Have I/they been doing it wrong? Thanks for bringing this up, Noah. Do not doubt that I thought hard about my decision to sign your key. I've also just reviewed the whole FAQ at https://www.apache.org/dev/release-signing and will subsequently be transitioning my key to a stronger one. I will, perhaps, refrain from publishing any key signings using that beyond those people I've personally met. -Randall