From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Td8qT-0004hZ-JS for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 00:16:13 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.175 as permitted sender) client-ip=209.85.210.175; envelope-from=gmaxwell@gmail.com; helo=mail-ia0-f175.google.com; Received: from mail-ia0-f175.google.com ([209.85.210.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Td8qS-00021I-Re for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 00:16:13 +0000 Received: by mail-ia0-f175.google.com with SMTP id z3so8679253iad.34 for ; Mon, 26 Nov 2012 16:16:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.37.133 with SMTP id y5mr13599206igj.8.1353975367613; Mon, 26 Nov 2012 16:16:07 -0800 (PST) Received: by 10.64.171.73 with HTTP; Mon, 26 Nov 2012 16:16:07 -0800 (PST) In-Reply-To: <201211262344.03385.luke@dashjr.org> References: <201211262319.37533.luke@dashjr.org> <201211262344.03385.luke@dashjr.org> Date: Mon, 26 Nov 2012 19:16:07 -0500 Message-ID: From: Gregory Maxwell To: Luke-Jr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Td8qS-00021I-Re Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 00:16:14 -0000 On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote: > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: >> Obviously the state of the world with browsers is not that good... but >> in our own UAs we can do better and get closer to that. > > This effectively centralizes Bitcoin (at least in the eyes of many) and e= ven > if each competing client had their own list, you'd be back to the origina= l > "problem" of not being sure your CA is on all lists. Thats the CA model generally. It _is_ a distributed-centralized model in practice. >> Would you find it acceptable if something supported a static whitelist >> plus a OS provided list minus a user configured blacklist and the >> ability for sophisticated users to disable the whitelist? > > How is this whitelist any different from the list of CAs included by defa= ult > with every OS? Because the list is not identical (and of course, couldn't be without centralizing control of all OSes :P ) meaning that the software has to be setup in a way where false-positive authentication failures are a common thing (terrible for user security) or merchants have to waste a bunch of time, probably unsuccessfully, figuring out what certs work sufficiently 'everwhere' and likely end up handing over extortion level fees to the most well established CAs that happen to be included on the oldest and most obscure things. Taking=E2=80=94 say=E2=80=94 the intersection of Chrome, Webkit, and Firefo= x's CA list as of the first of the year every year and putting the result on a whitelist would be a possible nothing-up-my-sleeve approach which is not as limited as having some users subject to the WinXP cert list, which IIRC is very limited (but not in a way that improves security!). Jeff wrote: > Self-signed certs are quite common, because it is easier, while being > more secure than http:// Uhh. Really? Well, I agree with you that they should be (I unsuccessfully lobbied browser vendors to make self-signed https on http URLs JustWork and simply hide all user visible evidence of security), but the really nasty warnings on those sites undermines the security of the sites _and_ of other HTTPS sites because it conditions users to click ignore-ignore-ignore. I don't think they are all that common. One thing which I think will be hard for us in this discussion is being sensitive to the (quite justified!) concerns that the current CA system is absolute rubbish, both terrible for security, usability, and an unreasonable barrier to entry relative to the provided security=E2=80=94 without allowing the discussion to be usurped by everyone's pet replacement, which there are a great many of with varying feasibility and security. Perhaps we should agree to talk about everything _except_ that first?