From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YGUlU-0006Wz-Cg for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 15:42:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.177 as permitted sender) client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f177.google.com; Received: from mail-wi0-f177.google.com ([209.85.212.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YGUlT-00055l-6f for bitcoin-development@lists.sourceforge.net; Wed, 28 Jan 2015 15:42:48 +0000 Received: by mail-wi0-f177.google.com with SMTP id r20so12781887wiv.4 for ; Wed, 28 Jan 2015 07:42:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.37.77 with SMTP id w13mr8390391wij.66.1422459762153; Wed, 28 Jan 2015 07:42:42 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Wed, 28 Jan 2015 07:42:42 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 16:42:42 +0100 X-Google-Sender-Auth: V0oaR9lRiFFbyTE2CXReRQNQ0Uk Message-ID: From: Mike Hearn To: Nicolas DORIER Content-Type: multipart/alternative; boundary=e89a8f647021d49ffa050db8382b 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: 1YGUlT-00055l-6f 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 15:42:48 -0000 --e89a8f647021d49ffa050db8382b Content-Type: text/plain; charset=UTF-8 > > 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. --e89a8f647021d49ffa050db8382b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the other hand, if= you charge 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 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 us= e 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 b= itcoinj by default to avoid cases where BIP70 requests work on some platfor= ms and not others, although the developer can easily override this and use = the OS root store instead.
=C2=A0
Of all possible solut= ions, using a third party service to convert things to JSON is one of the l= east obvious and highest effort. I don't know anyone else who arrived a= t such a conclusion and respectfully disagree that this is a problem with t= he design choices in BIP70. It sounds like a bizarre hack around lack of fe= atures in whatever runtime you're using.

--e89a8f647021d49ffa050db8382b--