1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
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 <mh.in.england@gmail.com>) id 1Td85H-0004Gz-4f
for bitcoin-development@lists.sourceforge.net;
Mon, 26 Nov 2012 23:27:27 +0000
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;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Td85E-0004yd-W7
for bitcoin-development@lists.sourceforge.net;
Mon, 26 Nov 2012 23:27:27 +0000
Received: by mail-oa0-f47.google.com with SMTP id h1so12475273oag.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 26 Nov 2012 15:27:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.171.164 with SMTP id av4mr10608243oec.59.1353972439584;
Mon, 26 Nov 2012 15:27:19 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Mon, 26 Nov 2012 15:27:19 -0800 (PST)
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
X-Google-Sender-Auth: UcKi9HFeoVH7oau_QmwKCvdVCss
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
X-Spam-Score: -1.2 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1Td85E-0004yd-W7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2012 23:27:27 -0000
> 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.
|
