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 m...@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
