Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UVJgJ-00039I-OS for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 10:45:39 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.46 as permitted sender) client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f46.google.com; Received: from mail-oa0-f46.google.com ([209.85.219.46]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UVJgI-0004Au-Q3 for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 10:45:39 +0000 Received: by mail-oa0-f46.google.com with SMTP id k3so2650760oag.19 for ; Thu, 25 Apr 2013 03:45:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.28.37 with SMTP id y5mr15859978oeg.134.1366886733435; Thu, 25 Apr 2013 03:45:33 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Thu, 25 Apr 2013 03:45:33 -0700 (PDT) In-Reply-To: <20130425102853.GA31573@crunch> References: <20130425095855.GA30535@crunch> <20130425102853.GA31573@crunch> Date: Thu, 25 Apr 2013 12:45:33 +0200 X-Google-Sender-Auth: I8LxTfnSieoOOIPZWTvdc89boZ0 Message-ID: From: Mike Hearn To: timo.hanke@web.de Content-Type: multipart/alternative; boundary=e89a8fb1f7f031dd3704db2d1ec0 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: 1UVJgI-0004Au-Q3 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 10:45:39 -0000 --e89a8fb1f7f031dd3704db2d1ec0 Content-Type: text/plain; charset=UTF-8 > > > 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. So I don't see how you can have a payment request signing key that's safer than an SSL key. As Jeremy notes, CAs will not issue you intermediate certificates. Perhaps if one existed that would do the necessary things for a reasonable price you could indeed give yourself an offline intermediate cert and then use that to sign one cert for SSL and another for payment request signing, but as far as anyone is aware no such CA exists. The interesting case is where the thing signing payment requests is less trusted than the web server. The scenario you're trying to solve is the inverse - the payment request signing process is more trusted than the web server. But unless/until the CA landscape changes we don't have a way to implement that. --e89a8fb1f7f031dd3704db2d1ec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> That's a pointless go= al to try and solve right now, because the SSL
> PKI cannot handle compromised web servers and so neither can we (with<= br> > 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&q= uot; keys
(certs). So he can clearly live with the SSL PKI being "less trusted&q= uot;
for his purpose.

Yes, but my point is= if the SSL key lives on the web server, and there are CAs that issue you c= erts 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.

So I don't see how you can have a payme= nt request signing key that's safer than an SSL key. As Jeremy notes, C= As will not issue you intermediate certificates. Perhaps if one existed tha= t would do the necessary things for a reasonable price you could indeed giv= e yourself an offline intermediate cert and then use that to sign one cert = for SSL and another for payment request signing, but as far as anyone is aw= are no such CA exists.

The interesting case is where the thing sig= ning payment requests is less trusted than the web server. The scenario you= 're trying to solve is the inverse - the payment request signing proces= s is more trusted than the web server. But unless/until the CA landscape ch= anges we don't have a way to implement that.
--e89a8fb1f7f031dd3704db2d1ec0--