Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.41 as permitted sender)
	client-ip=209.85.219.41; envelope-from=voisine@gmail.com;
	helo=mail-oa0-f41.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP15TKPcWnjdnfbRd9KxrS_5F=07gTL1DxyMo1os-sVOpA@mail.gmail.com>
References: <CANEZrP15TKPcWnjdnfbRd9KxrS_5F=07gTL1DxyMo1os-sVOpA@mail.gmail.com>
Date: Fri, 2 May 2014 12:21:41 -0700
Message-ID: <CACq0ZD6d1teN+MZM9Xx2EOX_OSPt5x7XmGtujT0DgBp0de-g5Q@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 implementation guidance
Precedence: list

At the moment BIP70 specifically requires that a request be rejected
if validation fails, so that should be fixed that sooner rather than
later:

"The recipient must verify the certificate chain according to
[RFC5280] and reject the PaymentRequest if any validation failure
occurs."

Aaron

There's no trick to being a humorist when you have the whole
government working for you -- Will Rodgers


On Fri, May 2, 2014 at 8:39 AM, Mike Hearn <mike@plan99.net> wrote:
> A bunch of different people either have implemented or are implementing
> BIP70 at the moment. Here's a bunch of things I've been telling people in
> response to questions. At some point I'll submit a pull req with this stuff
> in but for now it's just an email.
>
> Error handling during signature checking
>
> I've had queries around the right behaviour here. BIP 70 is underspecified
> and we should fix it IMO. If PKI checking fails you should just treat the
> request as if it's unsigned. The reason is that there is no incentive for an
> attacker to break the signature instead of just removing it entirely, so an
> attacker would never trigger any error flows you put in. However, someone
> who is signing their request with an unknown CA or using an upgraded version
> of the protocol that isn't entirely backwards compatible could trigger
> signature checking failure.
>
> Therefore, in order to make introducing new (possibly community run) CA's or
> new variations on signing possible, please treat any errors as if there was
> no signature at all. This is not what browsers do,  but browsers have an
> advantage - they were already given an identity and told to expect a secure
> protocol when the user typed in the web address with an https:// prefix (or
> clicked a link). Unfortunately a Bitcoin wallet has no context like this.
>
> One person asked me whether this makes the whole scheme pointless because a
> MITM can just delete the signature. The answer is no - downgrade attacks are
> always possible on systems that start out insecure. The solution is to train
> users to expect the upgrade and refuse to go ahead if it's not there.
> Training users to expect signed payment requests will be a big task similar
> to the way the browser industry trained users to look for the padlock when
> typing in credit card details, but it must be done.
>
> Because wallets lack context there's no equivalent to HSTS for us either. So
> in your GUI's try to train the user - when showing a signed payment request,
> tell them to expect the recipient name to appear in future and that they
> should not proceed if it doesn't. This gives us a kind of mental HSTS.
>
> Extended validation certs
>
> When a business is accepting payment, showing the name of the business is
> usually better than showing just the domain name, for a few reasons:
>
> Unless your domain name is your business name like blockchain.info, it looks
> better and gives more info.
>
> Domain names are more phishable than EV names, e.g. is the right name
> bitpay.com or bit-pay.com or bitpay.co.uk?
>
> More important: Someone who hacks your web server or DNS provider can
> silently get themselves a domain name SSL cert issued, probably without you
> noticing. Certificate transparency will eventually fix that but it's years
> away from full deployment. It's much harder for a hacker to get a bogus EV
> cert issued to them because there's a lot more checking involved.
>
> EV certs still have the domain name in the CN field, but they also have the
> business name in the OU field.
>
> In theory we are supposed to have extra code to check that a certificate
> really was subject to extended validation before showing the contents of
> this field. In practice either bitcoinj nor Bitcoin Core actually do, they
> just always trust it. It'd be nice to fix that in future.
>
> You should show the organisation data instead of the domain name if you find
> it, for EV certs.
>
> pki=none
>
> Signing is optional in BIP 70 for good reasons. One implementor told me they
> were considering rejecting unsigned payment requests. Do not do this! A MITM
> can easily rewrite the bitcoin URI to look as if BIP70 isn't in use at all.
>
> Even though today most (all?) payment requests you'll encounter are signed,
> it's important that signing is optional because in future we need individual
> people to start generating payment requests too, and many of them won't have
> any kind of memorisable digital identity. Plus other people just won't want
> to do it. BIP70 is about lots of features, signing is only one.
>
> S/MIME certs
>
> Email address certs look a bit different to SSL certs. You can get one for
> free from here
>
>     https://comodo.com/home/email-security/free-email-certificate.php
>
> In these certs the display name can be found in the Subject Alternative Name
> field with a type code of 1. Example code:
>
>
> https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d
>
> You won't encounter many of these today except on Gavin's test site, but in
> future people may wish to start creating and signing their own payment
> requests for individual purposes using these certs (especially as they are
> free). So please try to handle them correctly.
>
> Broadcast vs upload
>
> Please upload transactions and commit them to your wallet when the server
> responds with 200 OK, but expect the merchant to broadcast them. Don't give
> the user an option to pick - it's pointless as there's no obvious right
> answer.
>
> Testing
>
> You can find a test site here:
>
> http://bitcoincore.org/~gavin/createpaymentrequest.php
>
> It's testnet only. For testing regular payment requests on the main network,
> I use BitPay as they were the first seller-side implementation:
>
> http://bitgivefoundation.org/donate-now/
>
> Memo contents
>
> Please put something useful here, ideally what is actually being sold but
> failing that, the name of the merchant if you're a payment processor. Don't
> be like BitPay and put large random numbers in the memo field but nothing
> about what's actually purchased.
>
> This is not particularly important today except for cosmetic reasons,
> because wallets don't store the payment requests they saw to disk. But in
> future they will and then a properly signed memo field + the transactions
> used for payment give us a digital receipt. Receipts are useful for things
> like filing expense reports, proving a purchase when returning an item to a
> merchant, etc.
>
> Expiry times
>
> Don't be too aggressive with these. Although today it doesn't matter much,
> some users may be trying to pay from multi-party accounts that require
> multiple humans to coordinate to make a payment.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>