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
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <nicolas.dorier@gmail.com>) id 1YGVZZ-0000bQ-Da
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 16:34:33 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.44 as permitted sender)
client-ip=74.125.82.44; envelope-from=nicolas.dorier@gmail.com;
helo=mail-wg0-f44.google.com;
Received: from mail-wg0-f44.google.com ([74.125.82.44])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YGVZY-0000ob-36
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 16:34:33 +0000
Received: by mail-wg0-f44.google.com with SMTP id z12so21671228wgg.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 28 Jan 2015 08:34:27 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.96.4 with SMTP id do4mr8696115wib.46.1422462867059; Wed,
28 Jan 2015 08:34:27 -0800 (PST)
Sender: slashene@gmail.com
X-Google-Sender-Delegation: slashene@gmail.com
Received: by 10.194.92.112 with HTTP; Wed, 28 Jan 2015 08:34:26 -0800 (PST)
In-Reply-To: <CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@mail.gmail.com>
References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
<alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
<CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com>
<CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@mail.gmail.com>
Date: Wed, 28 Jan 2015 17:34:26 +0100
X-Google-Sender-Auth: YMDNKEkwPGZbgl-0g7-PUzRElvw
Message-ID: <CALYO6Xucf7xqE_4ykJqFyS_AEAT0X-1aGvYmA0WXzX7By0c0uQ@mail.gmail.com>
From: Nicolas DORIER <nicolas.dorier@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d04428f00e5b799050db8f17e
X-Spam-Score: -0.6 (/)
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
(nicolas.dorier[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1YGVZY-0000ob-36
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
encoding?
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: Wed, 28 Jan 2015 16:34:33 -0000
--f46d04428f00e5b799050db8f17e
Content-Type: text/plain; charset=UTF-8
My point is not that there is a limitation in BIP70. My point is that you
put the burden of certificate verification on developer's shoulder when we
can just leverage built in HTTPS support of the platform.
This make cross plateform dev a nightmare.
Sure I can use a snapshot of moz/apple/msft store. I depends on
BouncyCastle, as bitcoinj, so I theorically can use that way.
However, if you want to use your plateform's store, then you are toasted,
and the code for converting from BC X509 Certificate to one of each
plateform is not obvious and is a headache. Thing that could be just left
to the HTTPS support of your plateform.
Have you tried to do that on windows RT and IOS ? I tried, and I quickly
stopped doing that since it is not worth the effort. (Frankly I am not even
sure you can on win rt, since the API is a stripped down version of windows)
Why have you not heard about the problem ? (until now, because I have this
problem because I need to have the same codebase on
winrt/win/android/ios/tablets)
Because bitcoinj just rely either java's own abstraction of certificate or
on BC one. But I highly doubt they are using the plateform store, and even
if you theorically can, dealing with X509 is very prone to error... for
something that the plateform should just do for you.
Also, you bundle mozilla's store in bitcoinj, what happen when the store
change and your customer have not intent to use bitcoinj new version ? by
leveraging the plateform you benefit from automatic updates.
Also, does java stores deals with certificate revocations ? sure you can
theorically code that too... or just let the plateform deals with it.
BIP70 does not limit to anything but it is a gigantic pain in the ass for
easy cross development because of protobuff and embedded certificates.
BIP70 is a client side technology, not a performance and storage critical
data structure.
The only valid point of having embedded certificates is to allow the owner
of the website to be different from the merchant. But since merchants often
have their own website, a protocol without having to reinvent x509 would
have been better suited to current needs.
2015-01-28 16:42 GMT+01:00 Mike Hearn <mike@plan99.net>:
> On the other hand, if you charge the developer (and not the plateform) to
>> check certificate validity, it means that you have to develop a different
>> codebase for all plateform you are targeting, because each plateform store
>> trusted root certificate in a different manner with different APIs, and
>> also have different types representing a X509 Certificate.
>>
>
> That's what cross-platform abstraction libraries are for. Both Java and Qt
> provide a key store library that can load from either the OS root store or
> a custom one. If your chosen app platform doesn't, OK, then you'll have to
> make or find one yourself. Perhaps contribute it upstream or make it a
> library. But that's not a limitation of BIP70.
>
> Just as a reminder, there is no obligation to use the OS root store. You
> can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
> etc stores and load it in your app. We do this in bitcoinj by default to
> avoid cases where BIP70 requests work on some platforms and not others,
> although the developer can easily override this and use the OS root store
> instead.
>
> Of all possible solutions, using a third party service to convert things
> to JSON is one of the least obvious and highest effort. I don't know anyone
> else who arrived at such a conclusion and respectfully disagree that this
> is a problem with the design choices in BIP70. It sounds like a bizarre
> hack around lack of features in whatever runtime you're using.
>
>
--f46d04428f00e5b799050db8f17e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div>My point is not that th=
ere is a limitation in BIP70. My point is that you put the burden of certif=
icate verification on developer's shoulder when we can just leverage bu=
ilt in HTTPS support of the platform.<br></div>This make cross plateform de=
v a nightmare.<br><br></div>Sure I can use a snapshot of moz/apple/msft sto=
re. I depends on BouncyCastle, as bitcoinj, so I theorically can use that w=
ay.<br></div>However, if you want to use your plateform's store, then y=
ou are toasted, and the code for converting from BC X509 Certificate to one=
of each plateform is not obvious and is a headache. Thing that could be ju=
st left to the HTTPS support of your plateform.<br><br></div>Have you tried=
to do that on windows RT and IOS ? I tried, and I quickly stopped doing th=
at since it is not worth the effort. (Frankly I am not even sure you can on=
win rt, since the API is a stripped down version of windows)<br><br></div>=
Why have you not heard about the problem ? (until now, because I have this =
problem because I need to have the same codebase on winrt/win/android/ios/t=
ablets)<br></div>Because bitcoinj just rely either java's own abstracti=
on of certificate or on BC one. But I highly doubt they are using the plate=
form store, and even if you theorically can, dealing with X509 is very pron=
e to error... for something that the plateform should just do for you.<br><=
/div><div>Also, you bundle mozilla's store in bitcoinj, what happen whe=
n the store change and your customer have not intent to use bitcoinj new ve=
rsion ? by leveraging the plateform you benefit from automatic updates.<br>=
</div><div>Also, does java stores deals with certificate revocations ? sure=
you can theorically code that too... or just let the plateform deals with =
it.<br><br></div><div>BIP70 does not limit to anything but it is a gigantic=
pain in the ass for easy cross development because of protobuff and embedd=
ed certificates.<br></div><div>BIP70 is a client side technology, not a per=
formance and storage critical data structure.<br><br></div><div>The only va=
lid point of having embedded certificates is to allow the owner of the webs=
ite to be different from the merchant. But since merchants often have their=
own website, a protocol without having to reinvent x509 would have been be=
tter suited to current needs.<br></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">2015-01-28 16:42 GMT+01:00 Mike Hearn <span dir=3D"lt=
r"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net=
</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><div>On the other hand, if you ch=
arge the
developer (and not the plateform) to check certificate validity, it=20
means that you have to develop a different codebase for all plateform=20
you are targeting, because each plateform store trusted root certificate
in a different manner with different APIs, and also have different=20
types representing a X509 Certificate.<br></div></div></div></blockquote><d=
iv><br></div></span><div>That's what cross-platform abstraction librari=
es are for. Both Java and Qt provide a key store library that can load from=
either the OS root store or a custom one. If your chosen app platform does=
n't, OK, then you'll have to make or find one yourself. Perhaps con=
tribute it upstream or make it a library. But that's not a limitation o=
f BIP70.</div><div><br></div><div>Just as a reminder, there is no obligatio=
n to use the OS root store. You can (and quite possibly should) take a snap=
shot of the Mozilla/Apple/MSFT etc stores and load it in your app. We do th=
is in bitcoinj by default to avoid cases where BIP70 requests work on some =
platforms and not others, although the developer can easily override this a=
nd use the OS root store instead.</div><div>=C2=A0</div><div>Of all possibl=
e solutions, using a third party service to convert things to JSON is one o=
f the least obvious and highest effort. I don't know anyone else who ar=
rived at such a conclusion and respectfully disagree that this is a problem=
with the design choices in BIP70. It sounds like a bizarre hack around lac=
k of features in whatever runtime you're using.</div><div><br></div></d=
iv></div></div>
</blockquote></div><br></div></div>
--f46d04428f00e5b799050db8f17e--
|
