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
|
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 <timo.hanke@web.de>) id 1UVJQD-0005md-O1
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:29:01 +0000
Received: from mout.web.de ([212.227.15.3])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UVJQC-0002qG-OQ for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:29:01 +0000
Received: from crunch ([77.180.198.197]) by smtp.web.de (mrweb002) with ESMTPA
(Nemesis) id 0MMnD5-1UQ6tW47sF-008NM3;
Thu, 25 Apr 2013 12:28:54 +0200
Date: Thu, 25 Apr 2013 12:28:53 +0200
From: Timo Hanke <timo.hanke@web.de>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130425102853.GA31573@crunch>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
<20130425095855.GA30535@crunch>
<CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V02:K0:DILfqH3B7XF7ClaaVVgNT1sPqt9neIlXLe5h6h3lOWd
CDwAtR2isFgUsu/WB45tWx0rRRsR1pll03vv3qgOuT1snav+dY
bFHkFepMKi+j/ovlsqEIUwX5DNHwT+/HvKBQ4ITWCszc5uzraT
d1M1zNp+KPCfIE6Ucr78h4RXoJdWRdhLanJRclxZCZXBIXg7XQ
MQ5VUuFtbFwYmbECcCcEA==
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.15.3 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1UVJQC-0002qG-OQ
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
Reply-To: timo.hanke@web.de
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 10:29:01 -0000
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote:
> Chaining a custom cert onto the end doesn't work, at least not if your
> "end" is the SSL cert. Chaining it to the SSL cert defeats the OP's
> intention of "cold signing", as the SSL private key is usually kept
> online, therefore can't be used to sign a pubkey that is supposed to stay offline.
i meant: ^whose privkey is supposed to stay offline.
> the goal of all this is not to protect against web server compromise.
> The goal of this is to allow delegation of signing authority without giving the
> delegate the SSL private key.
This is not how I understand the OP, which I said I was addressing:
> The difficulty is that Payment Requests must be generated live, and
> therefore the key used to sign those requests must also be live,
> exposing the key to theft similar to a hot wallet. Steal the key,
> forge payment requests, and the payer sees a 'green box' but the coins
> go to the attacker. The question... is there a way to sign something
> once, with a key kept offline, which verifies the address in the
> Payment Request belongs to the payee?
> That's a pointless goal to try and solve right now, because the SSL
> PKI cannot handle compromised web servers and so neither can we (with
> v1 of the payments spec).
I don't think the OP intended to solve it "right now", i.e. in v1.
He differentiated between "most trusted" and "less trusted" keys
(certs). So he can clearly live with the SSL PKI being "less trusted"
for his purpose.
--
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
|
