Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Td8AW-0004qb-HI for bitcoin-development@lists.sourceforge.net; Mon, 26 Nov 2012 23:32:52 +0000 Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Td8AV-0005Ut-P6 for bitcoin-development@lists.sourceforge.net; Mon, 26 Nov 2012 23:32:52 +0000 Received: by mail-ia0-f175.google.com with SMTP id z3so8654354iad.34 for ; Mon, 26 Nov 2012 15:32:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.57.200 with SMTP id k8mr16448504igq.29.1353972766536; Mon, 26 Nov 2012 15:32:46 -0800 (PST) Received: by 10.64.171.73 with HTTP; Mon, 26 Nov 2012 15:32:46 -0800 (PST) In-Reply-To: <201211262319.37533.luke@dashjr.org> References: <201211262313.44463.luke@dashjr.org> <201211262319.37533.luke@dashjr.org> Date: Mon, 26 Nov 2012 18:32:46 -0500 Message-ID: From: Gregory Maxwell To: Luke-Jr Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.3 (-) 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.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Td8AV-0005Ut-P6 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: Mon, 26 Nov 2012 23:32:52 -0000 On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr wrote: > On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: >> They could be included as well of course, but from a seller >> perspective the most important thing is consistency. You have to be >> able to predict what CAs the user has, otherwise your invoice would >> appear in the UI as unverified and is subject to manipulation by >> viruses, etc. > > That's expected behaviour - except it's mainly be manipulated by *users*, not > viruses (which can just as easily manipulate whatever custom cert store we > use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no > matter who Joe is or what connections he has. > >> So using the OS cert store would effectively restrict merchants to the >> intersection of what ships in all the operating systems their users >> use, which could be unnecessarily restrictive. As far as I know, every >> browser has its own cert store for that reason. > > Browsers with this bug are not relevant IMO. This is messy. It's important to people to know that their cert will be accepted by ~everyone because non-acceptance looks like malice. If the cert system is actually to provide value then false positives need to be low enough that people can start calling in law enforcement, computer investigators, etc.. every time a cert failure happens. Otherwise there is little incentive for an attacker to not _try_. 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. 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? This way people could trust that if their cert is signed via one on the whitelist they'll work for ALL normal users.. and the UI can have very strong behavior that protects people (e.g. no 'click here to disable all security because tldr' button)... but advanced users who can deal with sorting out failure can still have complete control including OS based control.