From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UVJn5-0000K8-Lg for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 10:52:39 +0000 Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UVJn4-0003Gx-S1 for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 10:52:39 +0000 Received: by mail-oa0-f46.google.com with SMTP id k3so2654783oag.19 for ; Thu, 25 Apr 2013 03:52:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.179.42 with SMTP id dd10mr20453654oec.51.1366887153540; Thu, 25 Apr 2013 03:52:33 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.167.169 with HTTP; Thu, 25 Apr 2013 03:52:33 -0700 (PDT) In-Reply-To: References: <20130425095855.GA30535@crunch> <20130425102853.GA31573@crunch> Date: Thu, 25 Apr 2013 12:52:33 +0200 X-Google-Sender-Auth: WKDV6G9_GZkT3BboxQBL9To6v7g Message-ID: From: Mike Hearn To: timo.hanke@web.de Content-Type: multipart/alternative; boundary=089e011615883c269404db2d3771 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: 1UVJn4-0003Gx-S1 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:52:39 -0000 --089e011615883c269404db2d3771 Content-Type: text/plain; charset=UTF-8 > > 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. > Re-reading what I wrote, it's not really clear. Even if possible, the intermediate cert setup still wouldn't work for most merchants but I didn't make that clear. It might work for EV certs. For most sites that are just DV there's nothing you can do because CA verification is just "do you control this domain name". So if your web server is compromised it's game over. They can issue themselves a new cert, and what's more, unless wallets are checking revocation lists you can't stop them signing as you until their certificate expires. The process for getting an EV cert is harder and there, an offline restricted intermediate cert might make more sense because you could have a compromised SSL key whilst not having a compromised identity, but it's still not possible with todays CA policies. --089e011615883c269404db2d3771 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 inter= mediate certificates. Perhaps if one existed that would do the necessary th= ings for a reasonable price you could indeed give yourself an offline inter= mediate cert and then use that to sign one cert for SSL and another for pay= ment request signing, but as far as anyone is aware no such CA exists.

Re-rea= ding what I wrote, it's not really clear.

Even if possible, the intermediate cert setup still wouldn't wo= rk for most merchants but I didn't make that clear. It might work for E= V certs. For most sites that are just DV there's nothing you can do bec= ause CA verification is just "do you control this domain name". S= o if your web server is compromised it's game over. They can issue them= selves a new cert, and what's more, unless wallets are checking revocat= ion lists you can't stop them signing as you until their certificate ex= pires.

The process for getting an EV cert is harde= r and there, an offline restricted intermediate cert might make more sense = because you could have a compromised SSL key whilst not having a compromise= d identity, but it's still not possible with todays CA policies.
--089e011615883c269404db2d3771--