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
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
|
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 <etotheipi@gmail.com>) id 1SEoHL-0002rb-Sf
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Apr 2012 20:55:08 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=etotheipi@gmail.com;
helo=mail-vb0-f47.google.com;
Received: from mail-vb0-f47.google.com ([209.85.212.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SEoHK-00062O-PT
for bitcoin-development@lists.sourceforge.net;
Mon, 02 Apr 2012 20:55:07 +0000
Received: by vbbfr13 with SMTP id fr13so3065093vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 02 Apr 2012 13:55:01 -0700 (PDT)
Received: by 10.52.22.148 with SMTP id d20mr3791374vdf.102.1333400101257;
Mon, 02 Apr 2012 13:55:01 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id dr10sm1075567qab.14.2012.04.02.13.55.00
(version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:55:00 -0700 (PDT)
Message-ID: <4F7A1227.7070306@gmail.com>
Date: Mon, 02 Apr 2012 16:55:03 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative;
boundary="------------000201060401000405020701"
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
(etotheipi[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: 1SEoHK-00062O-PT
Subject: [Bitcoin-development] Signature Blocks and URI Sign Requests
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, 02 Apr 2012 20:55:08 -0000
This is a multi-part message in MIME format.
--------------000201060401000405020701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I would like to propose two things that are closely related. I will
start making BIPS if there's positive feedback. Sorry it's so long, but
I felt both should be in the same email...
_*(1) Signature Blocks* -- A more-robust, versatile, message-signing
exchange_
Satoshi client 0.6.0 introduced message signing, but I've been fairly
unimpressed with the implementation. Strictly speaking, it works, but
it's really not intended for "regular users." There is no indication of
what message was signed or what address signed it. Key recovery works
for the computers processing it, but the user has no idea what this
chunk of random data is. They don't even know if the message they
thought they signed is what's in the signature (along the lines of the
copy&paste virus, the message could be switched out without the user
noticing).
I have implemented Signature Blocks
<https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163> in
Armory (as of v0.55), which is a fully-functional expansion on the
idea. Along the lines of BIP 10, a signature block is a human-readable
chunk of data that immediately identifies the address and the message
that are being signed. It is easily copy&pasted via email or text
files, and is fairly compact for visual identification. Click the link
above to see an example signature block and an Armory screenshot of the
UI (which needs improvement, but still usable). The verification
process will include:
-- Check that the public key (included or recovered) matches the address
field.
-- Verify that the signature matches the included message for this
public key
-- The message is properly formatted with a standardized character set
and escape/replacement scheme for things like newlines or double-quotes.
gmaxwell already pointed out that key recovery makes the "Public Key"
field pointless. Okay fine -- I just don't have key recovery
implemented yet in Armory, and when I do I can ditch that field (or
simply make it optional). The point is to create a versatile,
human-readable standardized form, much like the BIP 0010
signature-collection scheme <https://en.bitcoin.it/wiki/BIP_0010>.
_*(2) Sign-Message URI scheme***-- Request signed messages from users
using URIs_
I had the idea that for certain services, the first funding address
could be used to identify the owner of an account, and all account
maintenance (such as cashouts) be done through signed messages with this
address. For instance, the user would need both a login password *and*
a signed message in order to make a withdrawal or purchase:
("Please withdraw 12.3 BTC from acct 1828349132 to address
1Hfr3jk2093f")_signed_by_A
This gives the service the ability to use two separate factors to
authenticate the request (username&password *and* access to unencrypted
wallet). This /could/ work with manual signature blocks alone... but
it's too many steps for regular users. However, I think it's workable
if we expand bitcoin URIs to include "Signature Requests".
The URI scheme would add a few parameters to the scheme, and would have
to have further replacement rules to make sure that messages are handled
properly. The general CONOPs would be (*Con*cept of *Op*eration*s*):
-- User navigates to "Withdraw funds" on webpage
-- Webpage has you fill in the details: from-account, to-address,
withdrawal amount
-- Webpage produces a clickable URI link that loads all the
information into your client, including addr-reqd-for-sig
-- Client asks for confirmation and passphrase (if necessary) then
produces a signature (and sig block if necessary)
-- URI may include reply-to field that tells it where to send the
siganture when it's ready
So the extra tags that would be needed would probably be:
"*requestSig*=True":
Flag to identify that this is a signing request URI
"*sigNeeded*=1Qjf3392k31h"
The address that needs to sign the message
"*message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f"
Some encoding of the message that can be parsed the
same way on all systems
"*replyurl*=http://requestor.com/sig_replies.asp?"
(Optional) After signing, application will submit the
signature to the replyurl
The reply url could be simply an http URL which will use bitcoin URI
syntax, with the fields above copied. Therefore, to complete the above
request, the application handling the request will simply send an HTTP
request to:
http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h&*message*=...&*signature*=1fb1893ac193...&*replySig*=True
Any thoughts? (I have no doubts that there are :) )
-Alan
--------------000201060401000405020701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
I would like to propose two things that are closely related. I will
start making BIPS if there's positive feedback. Sorry it's so long,
but I felt both should be in the same email...<br>
<br>
<br>
<u><b>(1) Signature Blocks</b> -- A more-robust, versatile,
message-signing exchange</u><br>
<br>
Satoshi client 0.6.0 introduced message signing, but I've been
fairly unimpressed with the implementation. Strictly speaking, it
works, but it's really not intended for "regular users." There is
no indication of what message was signed or what address signed it.
Key recovery works for the computers processing it, but the user has
no idea what this chunk of random data is. They don't even know if
the message they thought they signed is what's in the signature
(along the lines of the copy&paste virus, the message could be
switched out without the user noticing).<br>
<br>
I have implemented <a
href="https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163">Signature
Blocks</a> in Armory (as of v0.55), which is a fully-functional
expansion on the idea. Along the lines of BIP 10, a signature block
is a human-readable chunk of data that immediately identifies the
address and the message that are being signed. It is easily
copy&pasted via email or text files, and is fairly compact for
visual identification. Click the link above to see an example
signature block and an Armory screenshot of the UI (which needs
improvement, but still usable). The verification process will
include:<br>
<br>
-- Check that the public key (included or recovered) matches the
address field. <br>
-- Verify that the signature matches the included message for this
public key<br>
-- The message is properly formatted with a standardized character
set and escape/replacement scheme for things like newlines or
double-quotes.<br>
<br>
gmaxwell already pointed out that key recovery makes the "Public
Key" field pointless. Okay fine -- I just don't have key recovery
implemented yet in Armory, and when I do I can ditch that field (or
simply make it optional). The point is to create a versatile,
human-readable standardized form, much like the <a
href="https://en.bitcoin.it/wiki/BIP_0010">BIP 0010
signature-collection scheme</a>.<br>
<br>
<br>
<u><b>(2) Sign-Message URI scheme</b><b> </b>-- Request signed
messages from users using URIs</u><br>
<br>
I had the idea that for certain services, the first funding address
could be used to identify the owner of an account, and all account
maintenance (such as cashouts) be done through signed messages with
this address. For instance, the user would need both a login
password <b>and</b> a signed message in order to make a withdrawal
or purchase:<br>
<br>
<tt> ("Please withdraw 12.3 BTC from acct 1828349132 to address
1Hfr3jk2093f")_signed_by_A</tt><br>
<br>
This gives the service the ability to use two separate factors to
authenticate the request (username&password <b>and</b> access
to unencrypted wallet). This <i>could</i> work with manual
signature blocks alone... but it's too many steps for regular
users. However, I think it's workable if we expand bitcoin URIs to
include "Signature Requests".<br>
<br>
The URI scheme would add a few parameters to the scheme, and would
have to have further replacement rules to make sure that messages
are handled properly. The general CONOPs would be (<b>Con</b>cept
of <b>Op</b>eration<b>s</b>):<br>
<br>
-- User navigates to "Withdraw funds" on webpage<br>
-- Webpage has you fill in the details: from-account,
to-address, withdrawal amount<br>
-- Webpage produces a clickable URI link that loads all the
information into your client, including addr-reqd-for-sig<br>
-- Client asks for confirmation and passphrase (if necessary)
then produces a signature (and sig block if necessary)<br>
-- URI may include reply-to field that tells it where to send
the siganture when it's ready<br>
<br>
So the extra tags that would be needed would probably be:<br>
<br>
"<b>requestSig</b>=True": <br>
Flag to identify that this is a signing request URI<br>
"<b>sigNeeded</b>=1Qjf3392k31h" <br>
The address that needs to sign the message<br>
"<b>message</b>=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f"<br>
Some encoding of the message that can be parsed the
same way on all systems<br>
"<b>replyurl</b>=<a class="moz-txt-link-freetext" href="http://requestor.com/sig_replies.asp">http://requestor.com/sig_replies.asp</a>?"<br>
(Optional) After signing, application will submit
the signature to the replyurl<br>
<br>
The reply url could be simply an http URL which will use bitcoin URI
syntax, with the fields above copied. Therefore, to complete the
above request, the application handling the request will simply send
an HTTP request to:<br>
<br>
<tt> <a class="moz-txt-link-freetext" href="http://requestor.com/sig_replies.asp">http://requestor.com/sig_replies.asp</a>?<b>sigNeeded</b>=1Qjf3392k31h&<b>message</b>=...&<b>signature</b>=1fb1893ac193...&<b>replySig</b>=True</tt><br>
<br>
Any thoughts? (I have no doubts that there are :) )<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
--------------000201060401000405020701--
|
