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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Td8qT-0004hZ-JS
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 00:16:13 +0000
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;
Received: from mail-ia0-f175.google.com ([209.85.210.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Td8qS-00021I-Re
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 00:16:13 +0000
Received: by mail-ia0-f175.google.com with SMTP id z3so8679253iad.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 26 Nov 2012 16:16:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.37.133 with SMTP id y5mr13599206igj.8.1353975367613; Mon,
26 Nov 2012 16:16:07 -0800 (PST)
Received: by 10.64.171.73 with HTTP; Mon, 26 Nov 2012 16:16:07 -0800 (PST)
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
X-Spam-Score: -1.4 (-)
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.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Td8qS-00021I-Re
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: Tue, 27 Nov 2012 00:16:14 -0000
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?
|
