Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.47 as permitted sender)
	client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f47.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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: Tue, 27 Nov 2012 00:27:19 +0100
Message-ID: <CANEZrP1VzY2+1616Xqf3M9wxOn13__nXWJcUJvk5ASPBVu_Kaw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
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

> 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).

The point of using signed invoices as virus protection isn't to change
what the user sees on the infected host. The point is the invoice can
be relayed to a second device that isn't also compromised which then
independently renders a payment confirmation screen (like your mobile
phone), and it has an identifier in it that's useful to people, like
bitmit.net instead of an address.

If it was just showing you a Bitcoin address, that doesn't mean
anything to you so a virus on your PC could wait until you want to
make a large payment somewhere and swap out the address in use. You'd
never know it was the wrong address and you'd happily confirm on your
second device.

For this to work, the seller has to be able to predict what certs you
have in all your devices. If it's up to the OS vendors then it's hard
to know and in practice all that'll happen is somebody will compile a
list of CAs that are "known good" (ie, present in all deployed mobile
and desktop OS') and that'll be the minimal cert list. No different to
if it was hard-coded in the spec.

> 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.

Nothing says your wallet software can't provide cert management UI
like browsers do.

In practice I have a feeling that cert management UI is one of the
least used parts of a browser. I've used browsers for years and the
only time I've ever had to go into those screens was to manage
installation/removal of self signed certs used by various
organizations. I never manually revoked a root authority. When it was
necessary due to breaches (Comodo/DigiNotar) the browser makers
revoked them for me.