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
103
104
105
106
|
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 <gmaxwell@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
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 <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:32:52 -0000
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.
|
