From: Mike Hearn <mike@plan99•net>
To: Alan Reiner <etotheipi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Thu, 25 Apr 2013 11:08:26 +0200 [thread overview]
Message-ID: <CANEZrP2ynYUE8=8afKbbQVgJWoA5hRjV=nyT0Bmu-SAi1E1wOw@mail.gmail.com> (raw)
In-Reply-To: <517865CF.9050306@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]
(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.
[-- Attachment #2: Type: text/html, Size: 1948 bytes --]
next prev parent reply other threads:[~2013-04-25 9:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 23:01 Jeremy Spilman
2013-04-24 23:07 ` Alan Reiner
2013-04-25 9:08 ` Mike Hearn [this message]
[not found] <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
2013-04-25 9:58 ` Timo Hanke
2013-04-25 10:05 ` Mike Hearn
2013-04-25 10:28 ` Timo Hanke
2013-04-25 10:45 ` Mike Hearn
2013-04-25 10:52 ` Mike Hearn
2013-04-25 11:55 ` Timo Hanke
[not found] ` <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
2013-04-25 14:31 ` Mike Hearn
2013-04-25 19:12 ` Jeremy Spilman
2013-04-26 1:07 ` Gavin Andresen
2013-04-28 18:03 ` Timo Hanke
2013-04-29 18:40 ` Jeremy Spilman
2013-04-30 9:17 ` Mike Hearn
2013-04-30 11:32 ` Jouke Hofman
2013-04-30 13:14 ` Gavin Andresen
2013-04-30 17:17 ` Jeremy Spilman
2013-05-06 21:29 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP2ynYUE8=8afKbbQVgJWoA5hRjV=nyT0Bmu-SAi1E1wOw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=etotheipi@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox