From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Mike Hearn Message-ID: <20130425102853.GA31573@crunch> References: <20130425095855.GA30535@crunch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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