From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UVIAM-0001z1-7a for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 09:08:34 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.49 as permitted sender) client-ip=209.85.214.49; envelope-from=mh.in.england@gmail.com; helo=mail-bk0-f49.google.com; Received: from mail-bk0-f49.google.com ([209.85.214.49]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UVIAL-0004z2-5Z for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 09:08:34 +0000 Received: by mail-bk0-f49.google.com with SMTP id w5so1154731bku.36 for ; Thu, 25 Apr 2013 02:08:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.205.33.205 with SMTP id sp13mr7681051bkb.117.1366880906599; Thu, 25 Apr 2013 02:08:26 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.204.38.8 with HTTP; Thu, 25 Apr 2013 02:08:26 -0700 (PDT) In-Reply-To: <517865CF.9050306@gmail.com> References: <517865CF.9050306@gmail.com> Date: Thu, 25 Apr 2013 11:08:26 +0200 X-Google-Sender-Auth: ALBwoTOURmnYwlm18OwEyj0DVXY Message-ID: From: Mike Hearn To: Alan Reiner Content-Type: multipart/alternative; boundary=bcaec51ba46be39d5904db2bc2c5 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: 1UVIAL-0004z2-5Z 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 09:08:34 -0000 --bcaec51ba46be39d5904db2bc2c5 Content-Type: text/plain; charset=UTF-8 (for background: I did a lot of the design work with Gavin on the payment protocol and suggested/prototyped using x.509 in the way we do). So, I'm not a fan of weird hacks involving non-existent domain names. There's a clean way to implement this and we decided to punt on it for v1 in order to get something shippable, but if you're volunteering ... :) then indeed having a custom cert type that chains onto the end is the way to go. It doesn't have to be X.509. It can just be a regular protocol buffer. Even if we re-used X.509 it wouldn't be accepted by OpenSSL or any other SSL stack, so it wouldn't buy us anything and it's not like ASN.1 is easy to work with. Chaining an additional Bitcoin-specific cert onto the end also solves the problem of delegation ... a lot of merchants are using BitPay but probably don't want to share their SSL private keys with a third party. That means today the payments would show up as paid to BitPay Inc which is misleading and weird, they're just an intermediary. So if the merchant can run a simple command line tool that you point to the private key, and it spits out a signed protobuf that contains a new (ecdsa) public key and saves the private key to a file, then you can send that cert and key off to your payment processor. The identity is still taken from your CA cert but the actual signing keys used are different. Another use case - a company has a lot of roving sales agents, like in a supermarket or waiters at a restaurant. The company wants the agents to be able to sign with their corporate EV identity but the agents are not highly trusted. So they can be issued a 24-hour expiring Bitcoin-specific cert at the start of each working day and then they sign payment requests with that. --bcaec51ba46be39d5904db2bc2c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(for background: I did a lot of the design work= with Gavin on the payment protocol and suggested/prototyped using x.509 in= the way we do).

So, I'm not a fan of weird hacks i= nvolving non-existent domain names. There's a clean way to implement th= is and we decided to punt on it for v1 in order to get something shippable,= but if you're volunteering ... :) then indeed having a custom cert typ= e that chains onto the end is the way to go.

It doesn't have to be X.509. It can just be a regu= lar protocol buffer. Even if we re-used X.509 it wouldn't be accepted b= y OpenSSL or any other SSL stack, so it wouldn't buy us anything and it= 's not like ASN.1 is easy to work with. Chaining an additional Bitcoin-= specific cert onto the end also solves the problem of delegation ... a lot = of merchants are using BitPay but probably don't want to share their SS= L private keys with a third party. That means today the payments would show= up as paid to BitPay Inc which is misleading and weird, they're just a= n intermediary. So if the merchant can run a simple command line tool that = you point to the private key, and it spits out a signed protobuf that conta= ins a new (ecdsa) public key and saves the private key to a file, then you = can send that cert and key off to your payment processor. The identity is s= till taken from your CA cert but the actual signing keys used are different= .

Another use case - a company has a lot of r= oving sales agents, like in a supermarket or waiters at a restaurant. The c= ompany wants the agents to be able to sign with their corporate EV identity= but the agents are not highly trusted. So they can be issued a 24-hour exp= iring Bitcoin-specific cert at the start of each working day and then they = sign payment requests with that.


--bcaec51ba46be39d5904db2bc2c5--