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
|
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 <stephen@bitpay.com>) id 1Tm634-0004ir-Gh
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Dec 2012 17:06:14 +0000
Received: from mail-la0-f42.google.com ([209.85.215.42])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Tm632-0000Ii-6H
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Dec 2012 17:06:14 +0000
Received: by mail-la0-f42.google.com with SMTP id s15so5484133lag.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 21 Dec 2012 09:06:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:mime-version:x-originating-ip:in-reply-to:references
:from:date:message-id:subject:to:cc:content-type:x-gm-message-state;
bh=D7XpTIjolSn7BBD8B5kedHUaRPd0+Ee55Y58cBK3pq8=;
b=gx7yYo8fk78LDfwfjAEtvyD+488UGH0xeZta+SNcwfj2BWxpBF2Z5bP0jNeSUCHRz9
VOG7xw7NfkvmkTzXZeyErLtfMpuo+Xb5ykmhEQq0HJJxq74Wd0FBxC4kOT85dgLoEv9S
g52FUAEZ1lZlUnvqeuWCHyAA5QiYhnSyKtaA8bkQynNrcGyWmWO1/EYQoYJ7/m9gsajp
YAkmQyAsKJ7YzNtoLfz+p4oM0XUMRGqSo+PEACFpRF5pLu3ev446krytiAG4/TDFZyRT
mPtFyElk9cLBBA31xtSR22+sVnN/pXmYjhvjCg+s7yjjv/Evdug3g1jiPhRBr9PCoOxg
jVzg==
X-Received: by 10.152.47.75 with SMTP id b11mr12743716lan.14.1356109565384;
Fri, 21 Dec 2012 09:06:05 -0800 (PST)
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com
[209.85.215.53])
by mx.google.com with ESMTPS id v6sm4766948lbf.11.2012.12.21.09.06.02
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 21 Dec 2012 09:06:03 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id w12so5495756lag.12
for <bitcoin-development@lists.sourceforge.net>;
Fri, 21 Dec 2012 09:06:02 -0800 (PST)
Received: by 10.152.127.202 with SMTP id ni10mr12987423lab.6.1356109562118;
Fri, 21 Dec 2012 09:06:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.17.231 with HTTP; Fri, 21 Dec 2012 09:05:21 -0800 (PST)
X-Originating-IP: [71.204.90.78]
In-Reply-To: <CADb9v0Lc3HDpLO_ZdibPcxyrggACVfG+482oj72=986pfSc4mA@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>
<CAKaEYh+jJn0dPsGn_RnOy3NmWMc0F12Dffx2jYBUA=z+W45fWA@mail.gmail.com>
<CANEZrP1v9E1S1VA2p-pCzrobp8ueWZTf0r0stZ3JyJ==u_Zgxg@mail.gmail.com>
<CAKaEYhLbeBfJeLtBJTkX6S-MbqdWuQrcpNKpY2Czhhk3T6frmA@mail.gmail.com>
<CABsx9T1QjDfg-hKorJCk8Sdhf0fw9qQjV8R8EPNvU0m0nQF3tw@mail.gmail.com>
<CADb9v0K9xD+ndB-dJDkmPOuo1omrtMk3WTo238OjVcWoQ-CmXA@mail.gmail.com>
<CANEZrP162Q=hoqBQvLPm6rT=xNHMOtau42gDzRS4ddEtMFk5Uw@mail.gmail.com>
<CADb9v0Lc3HDpLO_ZdibPcxyrggACVfG+482oj72=986pfSc4mA@mail.gmail.com>
From: Stephen Pair <stephen@bitpay.com>
Date: Fri, 21 Dec 2012 12:05:21 -0500
Message-ID: <CADb9v0JaKFuDCY=NHRYQEjUAt4VKVm5pO2XZHgVttKYv-iQisg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d042c6aebba023604d15fdcfd
X-Gm-Message-State: ALoCoQn82EXRY02MEmbc1FqyJGIZHerjWgHFnMBZ88+NYNT6GMH1meTwd4U7+bpkOF7nFuPJ/Slt
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Tm632-0000Ii-6H
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: Fri, 21 Dec 2012 17:06:14 -0000
--f46d042c6aebba023604d15fdcfd
Content-Type: text/plain; charset=ISO-8859-1
The more I think about this topic, the more I think the first task at hand
is to implement secure, private messaging...the nature of any messages
(payment requests or otherwise) sent between wallets is such that it needs
to be secured. And the great thing is that it's easy to do and you don't
need to solve the PKI problem. Have the wallet maintain one or more ECC
key pairs for the purposes of signing and encrypting messages. Allow these
to be shared between wallets, or exported/imported, etc. You can punt on
the whole topic of verifying the others' public keys using PKI (I mean,
people use bitcoin addresses today without the use of any formal or
explicit PKI to verify them...people will make do without it for
communications keys just fine...and they can always use PGP or other PKI if
they feel the need...most people would just pick up the phone to verify a
friend's public key)...this also doesn't preclude the use of X.509 for the
merchant/customer scenario...
For a payment protocol, you could do something like this: use https & ssl
certificates/CAs as one method of obtaining an ECC public key...pki_type
could be "https" and pki_bytes could be a url for the https location to
download the ECC public key. The software would reject (or warn) if the
SSL certificate isn't considered valid by the normal CA validation process.
The wallet would not necessarily need to permanently store ECC public keys
obtained in this manner. This approach doesn't require people to obtain
new certificates just for bitcoin.
In fact, there would be very little difference to the proposed payments
protocol if this approach were taken...instead of using X.509 directly for
signing and encrypting messages, you are using it for signing and
encrypting the ECC public key exchange. And this allows people that don't
have web servers or SSL certificates to exchange their ECC public keys by
other means and be able to use this payment protocol as well as any others
that one could imagine. So, I actually think this is a better way of
keeping PKI out of the scope of the proposal.
Payment requests are just one kind of messaging between wallets. I've also
mentioned the "cheques" feature. I'm sure there are many more
possibilities. Having a uniform method of securing messages sent between
wallets (that doesn't depend on external tools) would be a great step
forward IMO.
--f46d042c6aebba023604d15fdcfd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The more I think about this topic, the more I think the fi=
rst task at hand is to implement secure, private messaging...the nature of =
any messages (payment requests or otherwise) sent between wallets is such t=
hat it needs to be secured. =A0And the great thing is that it's easy to=
do and you don't need to solve the PKI problem. =A0Have the wallet mai=
ntain one or more ECC key pairs for the purposes of signing and encrypting =
messages. =A0Allow these to be shared between wallets, or exported/imported=
, etc. =A0You can punt on the whole topic of verifying the others' publ=
ic keys using PKI (I mean, people use bitcoin addresses today without the u=
se of any formal or explicit PKI to verify them...people will make do witho=
ut it for communications keys just fine...and they can always use PGP or ot=
her PKI if they feel the need...most people would just pick up the phone to=
verify a friend's public key)...this also doesn't preclude the use=
of X.509 for the merchant/customer scenario...<div class=3D"gmail_extra">
</div><div><br></div><div>For a payment protocol, you could do something li=
ke this: use https & ssl certificates/CAs as one method of obtaining an=
ECC public key...pki_type could be "https" and pki_bytes could b=
e a url for the https location to download the ECC public key. =A0The softw=
are would reject (or warn) if the SSL certificate isn't considered vali=
d by the normal CA validation process. =A0The wallet would not necessarily =
need to permanently store ECC public keys obtained in this manner. =A0This =
approach doesn't require people to obtain new certificates just for bit=
coin.<br>
</div><div><br></div><div style>In fact, there would be very little differe=
nce to the proposed payments protocol if this approach were taken...instead=
of using X.509 directly for signing and encrypting messages, you are using=
it for signing and encrypting the ECC public key exchange. =A0And this all=
ows people that don't have web servers or SSL certificates to exchange =
their ECC public keys by other means and be able to use this payment protoc=
ol as well as any others that one could imagine. =A0So, I actually think th=
is is a better way of keeping PKI out of the scope of the proposal.</div>
<div><br></div><div style>Payment requests are just one kind of messaging b=
etween wallets. =A0I've also mentioned the "cheques" feature.=
=A0I'm sure there are many more possibilities. =A0Having a uniform met=
hod of securing messages sent between wallets (that doesn't depend on e=
xternal tools) would be a great step forward IMO.</div>
</div>
--f46d042c6aebba023604d15fdcfd--
|
