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; 
MIME-Version: 1.0
In-Reply-To: <201211262344.03385.luke@dashjr.org>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<201211262319.37533.luke@dashjr.org>
	<CAAS2fgS3f1RKzPnni4LXgXfSUrxSrB3+vhdmbsVz2Rs5pScL=w@mail.gmail.com>
	<201211262344.03385.luke@dashjr.org>
Date: Mon, 26 Nov 2012 19:16:07 -0500
Message-ID: <CAAS2fgTacBqX7_YpGzUxtqt9okeCeeufsG8d0CYnwVXPF_bu7w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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:44 PM, Luke-Jr <luke@dashjr.org> 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?