From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TkVzu-0000CH-Io for bitcoin-development@lists.sourceforge.net; Mon, 17 Dec 2012 08:24:26 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.175 as permitted sender) client-ip=209.85.210.175; envelope-from=melvincarvalho@gmail.com; helo=mail-ia0-f175.google.com; Received: from mail-ia0-f175.google.com ([209.85.210.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TkVzt-0004gF-Iv for bitcoin-development@lists.sourceforge.net; Mon, 17 Dec 2012 08:24:26 +0000 Received: by mail-ia0-f175.google.com with SMTP id z3so4904658iad.34 for ; Mon, 17 Dec 2012 00:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.236.104 with SMTP id ut8mr8343505igc.20.1355732660326; Mon, 17 Dec 2012 00:24:20 -0800 (PST) Received: by 10.42.61.203 with HTTP; Mon, 17 Dec 2012 00:24:19 -0800 (PST) In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> Date: Mon, 17 Dec 2012 09:24:19 +0100 Message-ID: From: Melvin Carvalho To: Jeff Garzik Content-Type: multipart/alternative; boundary=14dae9340343a10fc804d1081b72 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 (melvincarvalho[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: 1TkVzt-0004gF-Iv Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts 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: Mon, 17 Dec 2012 08:24:26 -0000 --14dae9340343a10fc804d1081b72 Content-Type: text/plain; charset=ISO-8859-1 On 17 December 2012 03:18, Jeff Garzik wrote: > On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho > wrote: > > On 3 December 2012 20:35, Mike Koss wrote: > >> It would also be really nice to migrate to textual representations of > data > >> structures as opposed to binary ones. The most successful internet > >> standards are based on text, making them that much more accessible for > >> developers to deal with them. JSON would be my preferred candidate. > >> > >> Why don't we sign the text representation of a (utf8) JSON, rather than > >> some complex encoding standard of JSON? That way the signatures are > simple > >> - and you need only retain the original textual representation of a > message > >> to validate the signature (as well as the decoded version, if you don't > want > >> to alway re-parse the message when writing programs that use it). > > > Binary formats can be challenging to deal with and convert to other > formats. > > The experiences in the PKI world of ASN.1 have not been great, in terms > of > > interop. It tends to create islands and silos. This is probably one of > the > > reasons why X.509 and GPG are fragmented and why we dont really have a > > widely deployed web of trust on the net. Another reason is simply lack > of > > developer resources to make tools. In that respect I think JSON offers > > significant advantages, though I am interested in the security issues > > raised. > > I thought this had already been covered up-thread? > > When creating something that must be hashed and/or compared, the data > structure must be created and reproduced precisely, byte-for-byte. > JSON offers significant -disadvantages- in this regard. With JSON, > you would therefore require an additional middle layer, between JSON > and application, ensuring that all fields are output in the same > order, all whitespace is not only perfectly preserved -- but reliably > generates identical whitespace output for identical inputs, given two > separate JSON implementations. > Apologies if I am a bit late to the thread. I bumped into someone that suggested I take a look at it. Will try and catch up! You raise a good point. Is there no good canonicalization algorithm / library for JSON? I think that provided that each JSON object has an identifier, canonicalization of JSON is not that hard. Then when you hash or sign the canonical form they can be compared reliably. > > -- > Jeff Garzik > exMULTI, Inc. > jgarzik@exmulti.com > --14dae9340343a10fc804d1081b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 17 December 2012 03:18, Jeff Garzik <= span dir=3D"ltr"><jgarzik@exmulti.com> wrote:
On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> On 3 December 2012 20:35, Mike Koss <mike@coinlab.com> wrote:
>> It would also be really nice to migrate to= textual representations of data
>> structures as opposed to binary ones. =A0The most successful inter= net
>> standards are based on text, making them that much more accessible= for
>> developers to deal with them. =A0 JSON would be my preferred candi= date.
>>
>> Why don't we sign the text representation of a (utf8) JSON, ra= ther than
>> some complex encoding standard of JSON? =A0That way the signatures= are simple
>> - and you need only retain the original textual representation of = a message
>> to validate the signature (as well as the decoded version, if you = don't want
>> to alway re-parse the message when writing programs that use it).<= br>
> Binary formats can be challenging to deal with and convert to other fo= rmats.
> The experiences in the PKI world of ASN.1 have not been great, in term= s of
> interop. =A0It tends to create islands and silos. =A0This is probably = one of the
> reasons why X.509 and GPG are fragmented and why we dont really have a=
> widely deployed web of trust on the net. =A0Another reason is simply l= ack of
> developer resources to make tools. =A0In that respect I think JSON off= ers
> significant advantages, though I am interested in the security issues<= br> > raised.

I thought this had already been covered up-thread?

When creating something that must be hashed and/or compared, the data
structure must be created and reproduced precisely, byte-for-byte.
JSON offers significant -disadvantages- in this regard. =A0With JSON,
you would therefore require an additional middle layer, between JSON
and application, ensuring that all fields are output in the same
order, all whitespace is not only perfectly preserved -- but reliably
generates identical whitespace output for identical inputs, given two
separate JSON implementations.

Apologies if I am a= bit late to the thread.=A0 I bumped into someone that suggested I take a l= ook at it.=A0 Will try and catch up!

You raise a good point.=A0
=
Is there no good canonicalization algorithm / library for JSON?

I th= ink that provided that each JSON object has an identifier, canonicalization= of JSON is not that hard.

Then when you hash or sign the canonical = form they can be compared reliably.
=A0

--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

--14dae9340343a10fc804d1081b72--