From: Mike Hearn <mike@plan99•net>
To: Dev Random <c1.devrandom@niftybox•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
Date: Sun, 2 Mar 2014 11:57:39 +0100 [thread overview]
Message-ID: <CANEZrP0+q3FNF4z89Ow-S8D5ZeBQAc64YGRPLGEfk2dWTWyfyA@mail.gmail.com> (raw)
In-Reply-To: <1393704464.6290.118.camel@mimiz>
[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]
On Sat, Mar 1, 2014 at 9:07 PM, Dev Random <c1.devrandom@niftybox•net>wrote:
> I'm wondering about the small business case. A small business or an
> individual might not have the technical expertise to perform the
> delegation signature.
If they take delivery of an SSL cert from the CA themselves, I don't see
why it'd be an issue. A simple GUI app can be produced that let's you open
the CA cert files and spits out the ExtendedCert file, which you then send
to the PP.
However, for small businesses like local shops, yes we don't expect them to
have a CA cert at the moment. Many of them do have small websites but for
those that don't, I don't think any great solutions exist yet. A virgin
market waiting to be tapped, perhaps ...
> Do you think it makes sense to have another scheme where a merchant can
> be name spaced under the payment processor? This would require just one
> additional field - the merchant identifier.
>
What is "the merchant identifier" exactly, and what does it mean? If this
question is left unresolved, then it doesn't mean anything and as such it's
equivalent to putting the merchant name in the memo field, which is fine
and what I expect to happen for now.
If it's resolved, then it makes payment processors into certificate
authorities themselves. I think such a solution would be spiffy, but it can
be done within the same framework we have today by just having wallets add
some Bitcoin specific roots to their trust store before PKI verification.
For example, BitPay could become their own CA that doesn't issue SSL certs
but rather "local business certs" that contain a verified street address.
Indeed X.509 certs include X.520 names, that's one reason they're so damn
complicated, and that's already got ways to express organisation names.
Actually setting such a scheme up requires real work though. If we want a
wallet to display something like:
"Pay to: Room 77, Graefestraße 77, Berlin"
then the question is, how is that verified and what does it mean when a
payment processor issues a cert containing it? Did someone physically visit
them? Did they just check on Google Maps? Does it mean it's a real
incorporated business or could it just be the address of a childs lemonade
stand?
My inclination would be to say that the ID requirements should be low and
cheap; for our primary use case of making hardware wallets secure, you
don't need robust ID verification, you just need to ensure a MITM can't
issue themselves duplicated ID's on the fly. Just posting a postcard with a
nonce on it would be sufficient IMO (or making a phone call to a number
obtained from a previously verified business listing).
Alternatively, a bitcoin payment processor CA could make visiting a
business, gathering photo evidence and issuing a cert into a kind of
microwork task with the PP/CA acting as a broker.
[-- Attachment #2: Type: text/html, Size: 3752 bytes --]
next prev parent reply other threads:[~2014-03-02 10:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 11:46 Mike Hearn
[not found] ` <1393704464.6290.118.camel@mimiz>
2014-03-01 20:42 ` Kevin Greene
2014-03-02 10:57 ` Mike Hearn [this message]
2014-03-02 10:38 ` Jeremy Spilman
2014-03-02 10:44 ` Mike Hearn
2014-03-02 15:20 ` Andreas Schildbach
2014-03-02 16:14 ` Mike Hearn
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=CANEZrP0+q3FNF4z89Ow-S8D5ZeBQAc64YGRPLGEfk2dWTWyfyA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=c1.devrandom@niftybox$(echo .)net \
/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