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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WK45a-00036w-CT
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 10:57:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.44 as permitted sender)
client-ip=209.85.219.44; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f44.google.com;
Received: from mail-oa0-f44.google.com ([209.85.219.44])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WK45Z-0001VT-CX
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 10:57:46 +0000
Received: by mail-oa0-f44.google.com with SMTP id n16so5887890oag.17
for <bitcoin-development@lists.sourceforge.net>;
Sun, 02 Mar 2014 02:57:40 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.161.81 with SMTP id xq17mr11513428oeb.3.1393757859961;
Sun, 02 Mar 2014 02:57:39 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Sun, 2 Mar 2014 02:57:39 -0800 (PST)
In-Reply-To: <1393704464.6290.118.camel@mimiz>
References: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
<1393704464.6290.118.camel@mimiz>
Date: Sun, 2 Mar 2014 11:57:39 +0100
X-Google-Sender-Auth: -hf_on0DKEv9yMIC9ysWRCVDSuU
Message-ID: <CANEZrP0+q3FNF4z89Ow-S8D5ZeBQAc64YGRPLGEfk2dWTWyfyA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Dev Random <c1.devrandom@niftybox.net>
Content-Type: multipart/alternative; boundary=089e01229a8c2563f204f39d8a98
X-Spam-Score: -0.5 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1WK45Z-0001VT-CX
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 extension to allow for identity
delegation
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: Sun, 02 Mar 2014 10:57:46 -0000
--089e01229a8c2563f204f39d8a98
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Mar 1, 2014 at 9:07 PM, Dev Random <c1.devrandom@niftybox.net>wrote=
:
> I'm wondering about the small business case. A small business or an
> individual might not have the technical expertise to perform the
> delegation signature.
If they take delivery of an SSL cert from the CA themselves, I don't see
why it'd be an issue. A simple GUI app can be produced that let's you open
the CA cert files and spits out the ExtendedCert file, which you then send
to the PP.
However, for small businesses like local shops, yes we don't expect them to
have a CA cert at the moment. Many of them do have small websites but for
those that don't, I don't think any great solutions exist yet. A virgin
market waiting to be tapped, perhaps ...
> Do you think it makes sense to have another scheme where a merchant can
> be name spaced under the payment processor? This would require just one
> additional field - the merchant identifier.
>
What is "the merchant identifier" exactly, and what does it mean? If this
question is left unresolved, then it doesn't mean anything and as such it's
equivalent to putting the merchant name in the memo field, which is fine
and what I expect to happen for now.
If it's resolved, then it makes payment processors into certificate
authorities themselves. I think such a solution would be spiffy, but it can
be done within the same framework we have today by just having wallets add
some Bitcoin specific roots to their trust store before PKI verification.
For example, BitPay could become their own CA that doesn't issue SSL certs
but rather "local business certs" that contain a verified street address.
Indeed X.509 certs include X.520 names, that's one reason they're so damn
complicated, and that's already got ways to express organisation names.
Actually setting such a scheme up requires real work though. If we want a
wallet to display something like:
"Pay to: Room 77, Graefestra=C3=9Fe 77, Berlin"
then the question is, how is that verified and what does it mean when a
payment processor issues a cert containing it? Did someone physically visit
them? Did they just check on Google Maps? Does it mean it's a real
incorporated business or could it just be the address of a childs lemonade
stand?
My inclination would be to say that the ID requirements should be low and
cheap; for our primary use case of making hardware wallets secure, you
don't need robust ID verification, you just need to ensure a MITM can't
issue themselves duplicated ID's on the fly. Just posting a postcard with a
nonce on it would be sufficient IMO (or making a phone call to a number
obtained from a previously verified business listing).
Alternatively, a bitcoin payment processor CA could make visiting a
business, gathering photo evidence and issuing a cert into a kind of
microwork task with the PP/CA acting as a broker.
--089e01229a8c2563f204f39d8a98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 1, 2014 at 9:07 PM, Dev Random <span dir=3D"ltr"><<a href=3D"mai=
lto:c1.devrandom@niftybox.net" target=3D"_blank">c1.devrandom@niftybox.net<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I'm wondering about the small business case. =C2=A0A s=
mall business or an<br>
individual might not have the technical expertise to perform the<br>
delegation signature.</blockquote><div><br></div><div>If they take delivery=
of an SSL cert from the CA themselves, I don't see why it'd be an =
issue. A simple GUI app can be produced that let's you open the CA cert=
files and spits out the ExtendedCert file, which you then send to the PP.<=
/div>
<div><br></div><div>However, for small businesses like local shops, yes we =
don't expect them to have a CA cert at the moment. Many of them do have=
small websites but for those that don't, I don't think any great s=
olutions exist yet. A virgin market waiting to be tapped, perhaps ...</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">Do you think it makes sense to have anoth=
er scheme where a merchant can<br>
be name spaced under the payment processor? =C2=A0This would require just o=
ne<br>
additional field - the merchant identifier.<br></blockquote><div><br></div>=
<div>What is "the merchant identifier" exactly, and what does it =
mean? If this question is left unresolved, then it doesn't mean anythin=
g and as such it's equivalent to putting the merchant name in the memo =
field, which is fine and what I expect to happen for now.=C2=A0</div>
<div><br></div><div>If it's resolved, then it makes payment processors =
into certificate authorities themselves. I think such a solution would be s=
piffy, but it can be done within the same framework we have today by just h=
aving wallets add some Bitcoin specific roots to their trust store before P=
KI verification. For example, BitPay could become their own CA that doesn&#=
39;t issue SSL certs but rather "local business certs" that conta=
in a verified street address. Indeed X.509 certs include X.520 names, that&=
#39;s one reason they're so damn complicated, and that's already go=
t ways to express organisation names.</div>
<div><br></div><div>Actually setting such a scheme up requires real work th=
ough. If we want a wallet to display something like:</div><div><br></div><d=
iv>=C2=A0 =C2=A0"Pay to: =C2=A0Room 77,=C2=A0Graefestra=C3=9Fe 77, Ber=
lin"</div><div><br>
</div><div>then the question is, how is that verified and what does it mean=
when a payment processor issues a cert containing it? Did someone physical=
ly visit them? Did they just check on Google Maps? Does it mean it's a =
real incorporated business or could it just be the address of a childs lemo=
nade stand?</div>
<div><br></div><div>My inclination would be to say that the ID requirements=
should be low and cheap; for our primary use case of making hardware walle=
ts secure, you don't need robust ID verification, you just need to ensu=
re a MITM can't issue themselves duplicated ID's on the fly. Just p=
osting a postcard with a nonce on it would be sufficient IMO (or making a p=
hone call to a number obtained from a previously verified business listing)=
.</div>
<div><br></div><div>Alternatively, a bitcoin payment processor CA could mak=
e visiting a business, gathering photo evidence and issuing a cert into a k=
ind of microwork task with the PP/CA acting as a broker.</div></div></div>
</div>
--089e01229a8c2563f204f39d8a98--
|
