[Bitcoin-development] BIP70 implementation guidance
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: 1. Unless your domain name *is* your business name like blockchain.info, it looks better and gives more info. 2. Domain names are more phishable than EV names, e.g. is the right name bitpay.com or bit-pay.com or bitpay.co.uk? 3. 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/createpaymen
Re: [Bitcoin-development] BIP70 implementation guidance
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 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 G
Re: [Bitcoin-development] BIP70 implementation guidance
> *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: > >1. Unless your domain name *is* your business name like blockchain.info, >it looks better and gives more info. > >2. Domain names are more phishable than EV names, e.g. is the right name >bitpay.com or bit-pay.com or bitpay.co.uk? > >3. 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. Well, many certs have something in the O field. That has nothing to do with EV - EV just mandates a particular set of validation requirements. > > 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. I agree that blindly showing the O field may not be ideal - there *may* conceivably be some CAs that include it without validation on their cheap certs (although most cheap certs simply don't include it). But it's not clear that EV or not is the right criterion here - there are certainly non-EV certs out there that are organisation validated. > You should show the organisation data instead of the domain name if you > find it, for EV certs. I have really mixed feelings about giving this privileged treatment exclusively to EV certs, for the simple reason that the rules around EV certs are iniquitous and some businesses are excluded. e.g. in the UK sole traders (that is, unincorporated businesses) can't get EV certs because the UK doesn't maintain a trade register of such businesses and therefore such businesses are incapable of satisfying the EV rules. That said, EV certs are here, now, and (sadly) supporting them is better than doing nothing... roy -- "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
Re: [Bitcoin-development] BIP70 implementation guidance
> > e.g. in the UK sole traders (that is, unincorporated businesses) can't > get EV certs because the UK doesn't maintain a trade register of such > businesses > Sole traders can just trade under their own name, or their email address, or their domain name, heck even their telephone number if someone sets up an SMS verifying CA. I don't worry too much about such things - the point of the cert is just to disambiguate the payment so people can't get confused into paying the wrong entity. Companies that can't get EV certs cause us pain indirectly by making users less certain about what they're expecting to see when they pay a company, making confusion attacks a bit easier, but I bet it'll be a minor issue in practice. -- "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
