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 ) 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 ; 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: References: Date: Wed, 28 Jan 2015 17:34:26 +0100 X-Google-Sender-Auth: YMDNKEkwPGZbgl-0g7-PUzRElvw Message-ID: From: Nicolas DORIER To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : > 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
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.
This make cross plateform de= v a nightmare.

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.
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.

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)

= 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)
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.
<= /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.
=
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 embedd= ed certificates.
BIP70 is a client side technology, not a per= formance and storage critical data structure.

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.

2015-01-28 16:42 GMT+01:00 Mike Hearn <mike@plan99.net= >:
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.

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.

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.
=C2=A0
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.


--f46d04428f00e5b799050db8f17e--