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
210
211
212
213
214
215
216
|
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 <melvincarvalho@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CA+8xBpeya92UR60_ba+xYycjONOOvYUcW4Fe+SNdWwpg7aWEHw@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
<20121129170713.GD6368@giles.gnomon.org.uk>
<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
<20121129185330.GE6368@giles.gnomon.org.uk>
<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
<CAErK2ChjAm-Zf11YXuBQeTQvahOEJNGiPSZaD-CQ=OU9K6HtZA@mail.gmail.com>
<CAKaEYh+OUD4kfxwSNQBCJXmj6Kwb8jy9Au=Mfrqr2sKv7SuHpg@mail.gmail.com>
<CA+8xBpeya92UR60_ba+xYycjONOOvYUcW4Fe+SNdWwpg7aWEHw@mail.gmail.com>
Date: Mon, 17 Dec 2012 09:24:19 +0100
Message-ID: <CAKaEYh+jJn0dPsGn_RnOy3NmWMc0F12Dffx2jYBUA=z+W45fWA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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 <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. 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
<br><br><div class=3D"gmail_quote">On 17 December 2012 03:18, Jeff Garzik <=
span dir=3D"ltr"><<a href=3D"mailto:jgarzik@exmulti.com" target=3D"_blan=
k">jgarzik@exmulti.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<div class=3D"im">On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho<br>
<<a href=3D"mailto:melvincarvalho@gmail.com">melvincarvalho@gmail.com</a=
>> wrote:<br>
> On 3 December 2012 20:35, Mike Koss <<a href=3D"mailto:mike@coinlab=
.com">mike@coinlab.com</a>> wrote:<br>
</div><div class=3D"im">>> It would also be really nice to migrate to=
textual representations of data<br>
>> structures as opposed to binary ones. =A0The most successful inter=
net<br>
>> standards are based on text, making them that much more accessible=
for<br>
>> developers to deal with them. =A0 JSON would be my preferred candi=
date.<br>
>><br>
>> Why don't we sign the text representation of a (utf8) JSON, ra=
ther than<br>
>> some complex encoding standard of JSON? =A0That way the signatures=
are simple<br>
>> - and you need only retain the original textual representation of =
a message<br>
>> to validate the signature (as well as the decoded version, if you =
don't want<br>
>> to alway re-parse the message when writing programs that use it).<=
br>
<br>
> Binary formats can be challenging to deal with and convert to other fo=
rmats.<br>
> The experiences in the PKI world of ASN.1 have not been great, in term=
s of<br>
> interop. =A0It tends to create islands and silos. =A0This is probably =
one of the<br>
> reasons why X.509 and GPG are fragmented and why we dont really have a=
<br>
> widely deployed web of trust on the net. =A0Another reason is simply l=
ack of<br>
> developer resources to make tools. =A0In that respect I think JSON off=
ers<br>
> significant advantages, though I am interested in the security issues<=
br>
> raised.<br>
<br>
</div>I thought this had already been covered up-thread?<br>
<br>
When creating something that must be hashed and/or compared, the data<br>
structure must be created and reproduced precisely, byte-for-byte.<br>
JSON offers significant -disadvantages- in this regard. =A0With JSON,<br>
you would therefore require an additional middle layer, between JSON<br>
and application, ensuring that all fields are output in the same<br>
order, all whitespace is not only perfectly preserved -- but reliably<br>
generates identical whitespace output for identical inputs, given two<br>
separate JSON implementations.<br></blockquote><div><br>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!<br><br>You raise a good point.=A0 <br>=
<br>
Is there no good canonicalization algorithm / library for JSON?<br><br>I th=
ink that provided that each JSON object has an identifier, canonicalization=
of JSON is not that hard.<br><br>Then when you hash or sign the canonical =
form they can be compared reliably.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Jeff Garzik<br>
exMULTI, Inc.<br>
<a href=3D"mailto:jgarzik@exmulti.com">jgarzik@exmulti.com</a><br>
</div></div></blockquote></div><br>
--14dae9340343a10fc804d1081b72--
|
