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; 
MIME-Version: 1.0
In-Reply-To: <201211262319.37533.luke@dashjr.org>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<201211262313.44463.luke@dashjr.org>
	<CANEZrP3nmUHbKsJVTL=mT62OwBU0bPj7S__1ep1KvyqSzsy1jQ@mail.gmail.com>
	<201211262319.37533.luke@dashjr.org>
Date: Mon, 26 Nov 2012 18:32:46 -0500
Message-ID: <CAAS2fgS3f1RKzPnni4LXgXfSUrxSrB3+vhdmbsVz2Rs5pScL=w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr <luke@dashjr.org> 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.