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)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Precedence: list
Reply-To: timo.hanke@web.de

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