On Wed, 28 Jan 2015, Nicolas DORIER wrote:
I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
Well x509 is an international standard in common use, you can't do much
better with regard to portability. Your suggestion about HTTPS makes
little sense, you do know what TLS
Sure I know that x509 is international standard. And that HTTPS uses TLS.
This is not my point, my point is that when we use HTTPS the developer
delegates certificates verification to the plateform he is running on, so
developer don't have to bother about it, making the implementation safer
and
I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
The choice should have been done to maximize portability, not to maximize
efficiency and flexibility.
What I ended up doing for having a similar codebase on all plateform is to
parse a BIP70 messages with the help of a web
Sure,
But the mobile targets, it is still easier to use Json + HTTPS, especially
when you want one code base for everything.
And as you said, developers need to think about fetching mozilla store time
to time, and check revocations themselves. This is not obvious thing to do,
and hard to test
It is not fear, it is field experience.
JSON has proven to be a bug generator for the reasons already stated.
JSON does not include type marshalling and input validation.
Protobufs/msgpack/etc. engineered those to occur automatically, because
that is an area shown by field experience to be a
It is not fear, it is field experience.
JSON has proven to be a bug generator for the reasons already stated.
To back Jeff up on this point, today we see this story:
http://www.theregister.co.uk/2015/01/27/trivial_hole_left_black_phones_open_to_plunder/
The maker of BlackPhone – a mobile
I'm frankly _horrified_ to learn that BitcoinJ ships its own root CA
certificates bundle. This means that, if a root CA gets breached and a
certificate gets revoked, all BitcoinJ-using software will be vulnerable
until BitcoinJ ships an update *and* the software in question pulls in the
new
I think we'll just have to agree to disagree on this one. I've implemented
BIP70 a couple of times now and didn't find it to be difficult. I know you
had odd problems with the C# protobuf implementation you were using but
library bugs can happen for any kind of programming.
I forgot to mention
why not allow both serializations and keep serialization format a
parameter, keep everyone happy.
http://twitter.com/gubatron
On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn m...@plan99.net wrote:
I think we'll just have to agree to disagree on this one. I've implemented
BIP70 a couple of times
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,
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
On Wednesday, 28 January 2015, at 5:19 pm, Giuseppe Mazzotta wrote:
On 28-01-15 16:42, Mike Hearn wrote:
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
Not to mention the tiresome and error-prone task of writing your own
JSON-to-schema marshalling code -- or something equivalent to the protobufs
compiler and libs for JSON.
protobufs -- and its modern competitors such as msgpack -- natively provide
type support in a way that must be hacked into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28-01-15 16:42, Mike Hearn wrote:
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
For the number of field there is in the spec, I don't consider having a
JSON to schama really worthwhile.
If you fear it is error prone, then we should provide some testing data for
the BIP70. (Which I already did for protobuf, but was rejected, because
deemed no useful thanks to the code
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.
Platforms that support HTTPS but not certificate handling are rare - I know
HTML5 is
Mike, I am not denying it is impossible to do all of that.
Just that it is not a trivial stuff to do to make it works everywhere, and
I think that it is not a good thing for a client side technology.
BIP70 has its use, and I understand why there is case where it is good to
ship the certs in the
17 matches
Mail list logo
