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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UVIAM-0001z1-7a
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 09:08:34 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.49 as permitted sender)
client-ip=209.85.214.49; envelope-from=mh.in.england@gmail.com;
helo=mail-bk0-f49.google.com;
Received: from mail-bk0-f49.google.com ([209.85.214.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UVIAL-0004z2-5Z
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 09:08:34 +0000
Received: by mail-bk0-f49.google.com with SMTP id w5so1154731bku.36
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 02:08:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.205.33.205 with SMTP id sp13mr7681051bkb.117.1366880906599;
Thu, 25 Apr 2013 02:08:26 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.204.38.8 with HTTP; Thu, 25 Apr 2013 02:08:26 -0700 (PDT)
In-Reply-To: <517865CF.9050306@gmail.com>
References: <CA+CODZFNo6KRW-wKvVbnesQMEm9k5MEoTPEPXepCKKnzt+1E6g@mail.gmail.com>
<517865CF.9050306@gmail.com>
Date: Thu, 25 Apr 2013 11:08:26 +0200
X-Google-Sender-Auth: ALBwoTOURmnYwlm18OwEyj0DVXY
Message-ID: <CANEZrP2ynYUE8=8afKbbQVgJWoA5hRjV=nyT0Bmu-SAi1E1wOw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51ba46be39d5904db2bc2c5
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1UVIAL-0004z2-5Z
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment 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: Thu, 25 Apr 2013 09:08:34 -0000
--bcaec51ba46be39d5904db2bc2c5
Content-Type: text/plain; charset=UTF-8
(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).
So, I'm not a fan of weird hacks involving non-existent domain names.
There's a clean way to implement this and we decided to punt on it for v1
in order to get something shippable, but if you're volunteering ... :) then
indeed having a custom cert type that chains onto the end is the way to go.
It doesn't have to be X.509. It can just be a regular protocol buffer. Even
if we re-used X.509 it wouldn't be accepted by OpenSSL or any other SSL
stack, so it wouldn't buy us anything and it's not like ASN.1 is easy to
work with. Chaining an additional Bitcoin-specific cert onto the end also
solves the problem of delegation ... a lot of merchants are using BitPay
but probably don't want to share their SSL private keys with a third party.
That means today the payments would show up as paid to BitPay Inc which is
misleading and weird, they're just an intermediary. So if the merchant can
run a simple command line tool that you point to the private key, and it
spits out a signed protobuf that contains a new (ecdsa) public key and
saves the private key to a file, then you can send that cert and key off to
your payment processor. The identity is still taken from your CA cert but
the actual signing keys used are different.
Another use case - a company has a lot of roving sales agents, like in a
supermarket or waiters at a restaurant. The company wants the agents to be
able to sign with their corporate EV identity but the agents are not highly
trusted. So they can be issued a 24-hour expiring Bitcoin-specific cert at
the start of each working day and then they sign payment requests with that.
--bcaec51ba46be39d5904db2bc2c5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style>(for background: I did a lot of the design work=
with Gavin on the payment protocol and suggested/prototyped using x.509 in=
the way we do).</div><div><br></div>So, I'm not a fan of weird hacks i=
nvolving non-existent domain names. There's a clean way to implement th=
is and we decided to punt on it for v1 in order to get something shippable,=
but if you're volunteering ... :) then indeed having a custom cert typ=
e that chains onto the end is the way to go.<div>
<br></div><div style>It doesn't have to be X.509. It can just be a regu=
lar protocol buffer. Even if we re-used X.509 it wouldn't be accepted b=
y OpenSSL or any other SSL stack, so it wouldn't buy us anything and it=
's not like ASN.1 is easy to work with. Chaining an additional Bitcoin-=
specific cert onto the end also solves the problem of delegation ... a lot =
of merchants are using BitPay but probably don't want to share their SS=
L private keys with a third party. That means today the payments would show=
up as paid to BitPay Inc which is misleading and weird, they're just a=
n intermediary. So if the merchant can run a simple command line tool that =
you point to the private key, and it spits out a signed protobuf that conta=
ins a new (ecdsa) public key and saves the private key to a file, then you =
can send that cert and key off to your payment processor. The identity is s=
till taken from your CA cert but the actual signing keys used are different=
.</div>
<div style><br></div><div style>Another use case - a company has a lot of r=
oving sales agents, like in a supermarket or waiters at a restaurant. The c=
ompany wants the agents to be able to sign with their corporate EV identity=
but the agents are not highly trusted. So they can be issued a 24-hour exp=
iring Bitcoin-specific cert at the start of each working day and then they =
sign payment requests with that.</div>
<div style><br></div><div style><br></div></div>
--bcaec51ba46be39d5904db2bc2c5--
|
