diff options
| author | Mike Hearn <mike@plan99.net> | 2013-04-25 11:08:26 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-04-25 09:08:34 +0000 |
| commit | b1ed4f0bfb21c88d55caf2324005c91f53b89372 (patch) | |
| tree | a1a5ad7f3844ec94ad7424fab7c16e68fb4915b8 | |
| parent | 7f0283fd6a0845c8dcab7ed05e81fb45088f00b9 (diff) | |
| download | pi-bitcoindev-b1ed4f0bfb21c88d55caf2324005c91f53b89372.tar.gz pi-bitcoindev-b1ed4f0bfb21c88d55caf2324005c91f53b89372.zip | |
Re: [Bitcoin-development] Cold Signing Payment Requests
| -rw-r--r-- | c8/adbdb7e200e95669b564a22f220c09abd13213 | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/c8/adbdb7e200e95669b564a22f220c09abd13213 b/c8/adbdb7e200e95669b564a22f220c09abd13213 new file mode 100644 index 000000000..fb37725b3 --- /dev/null +++ b/c8/adbdb7e200e95669b564a22f220c09abd13213 @@ -0,0 +1,127 @@ +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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CA+CODZFNo6KRW-wKvVbnesQMEm9k5MEoTPEPXepCKKnzt+1E6g@mail.gmail.com> + <517865CF.9050306@gmail.com> +Date: Thu, 25 Apr 2013 11:08:26 +0200 +X-Google-Sender-Auth: ALBwoTOURmnYwlm18OwEyj0DVXY +Message-ID: <CANEZrP2ynYUE8=8afKbbQVgJWoA5hRjV=nyT0Bmu-SAi1E1wOw@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Alan Reiner <etotheipi@gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 + +<div dir=3D"ltr"><div style>(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).</div><div><br></div>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.<div> +<br></div><div style>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= +.</div> +<div style><br></div><div style>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.</div> +<div style><br></div><div style><br></div></div> + +--bcaec51ba46be39d5904db2bc2c5-- + + |