Date: Thu, 25 Apr 2013 13:55:59 +0200
From: Timo Hanke <timo.hanke@web.de>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130425115559.GA32463@crunch>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
	<20130425095855.GA30535@crunch>
	<CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
	<20130425102853.GA31573@crunch>
	<CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@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:45:33PM +0200, Mike Hearn wrote:
>     > 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.
> 
> 
> Yes, but my point is if the SSL key lives on the web server, and there are CAs
> that issue you certs based on control of a web server at the given domain name
> (there are), then you can simply issue yourself a new SSL cert with whatever
> data in it you want and pose as the merchant.

True, I forgot about that, though we already had discussed this in the
past..

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 7DA8