From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UVJ3F-0008BG-Fs for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 10:05:17 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.50 as permitted sender) client-ip=209.85.214.50; envelope-from=mh.in.england@gmail.com; helo=mail-bk0-f50.google.com; Received: from mail-bk0-f50.google.com ([209.85.214.50]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UVJ3B-0006OV-KN for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 10:05:17 +0000 Received: by mail-bk0-f50.google.com with SMTP id ik5so1174275bkc.37 for ; Thu, 25 Apr 2013 03:05:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.204.224.135 with SMTP id io7mr13803660bkb.46.1366884307186; Thu, 25 Apr 2013 03:05:07 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.204.38.8 with HTTP; Thu, 25 Apr 2013 03:05:06 -0700 (PDT) In-Reply-To: <20130425095855.GA30535@crunch> References: <20130425095855.GA30535@crunch> Date: Thu, 25 Apr 2013 12:05:06 +0200 X-Google-Sender-Auth: G1DZB751ZJIzjwS7CbGKDWGl98c Message-ID: From: Mike Hearn To: timo.hanke@web.de Content-Type: multipart/alternative; boundary=485b3970d5b89476e404db2c8dde 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: 1UVJ3B-0006OV-KN 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:05:17 -0000 --485b3970d5b89476e404db2c8dde Content-Type: text/plain; charset=UTF-8 > 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. What you wrote doesn't make any sense to me, sorry. Yes, SSL private keys are kept online. That's irrelevant - the goal of all this is not to protect against web server compromise. 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). The goal of this is to allow delegation of signing authority without giving the delegate the SSL private key. --485b3970d5b89476e404db2c8dde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
Chaining a custom cert onto the end doesn= 9;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 ke= pt
online, therefore can't be used to sign a pubkey that is supposed to stay offline.

What you wrote doesn= 9;t make any sense to me, sorry.

Yes, = SSL private keys are kept online. That's irrelevant - the goal of all t= his is not to protect against web server compromise. That's a pointless= goal to try and solve right now, because the SSL PKI cannot handle comprom= ised web servers and so neither can we (with v1 of the payments spec).

The goal of this is to allow delegation of = signing authority without giving the delegate the SSL private key.

--485b3970d5b89476e404db2c8dde--