If a webshop using a deterministic wallet makes its master public key public (as it should), then a shopper's wallet app can verify that the payment address associated with her invoice belongs to the merchant's wallet.
E.g a merchant could publish its master public key on its web site and on social networks: a bitcoin wallet app could double check or triple check the master public key against the payment address before making any payment.
No need for a CA.
I dvelopped two apps to demonstrate this use case (those are RoR apps that I intend to open source when I fidn the time to do so):
the webshop is deployed on microbitcoin.net and the address verification app (still in beta) is on bitcoinrad.io.
You can try out bitcoinrad.io with your own electrum master public key and addresses.
The bitcoinrad.io type service should be duplicated so that multiple (decentralized) verification sources are available to merchants using deterministic wallets.
Multiple verification sources, possibly exposing a unified API, would greatly reduce the risks of a MITM attack.
Topic: Invoices/Payments/Receipts proposal discussion - page 13. (Read 24728 times)
Doesn't this introduce liability issues? I mean if there is a central authority claiming to authenticate one entity to another and someone fakes a certificate as is certainly possible since its just ssl overlay and gets away with coins wouldn't they become liable?
If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?
I think Google, Microsoft and others have *proven* themselves to be inherently untrustworthy and yes I do think it will be a concern for the future of Bitcoin if say the NSA starts making decisions about future security aspects.
Certificate transparency is not a "suggestion", it's actual working code with an open specification that real CA's have started signing up to.
If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?
If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?
Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.
The enemy of better is perfect.
The enemy of better is perfect.
Sure but I would not use SSL for anything I really cared about (if it really mattered I would trust GPG).
I think the payment protocol idea itself is fine but we do need to have our eyes wide open when it comes to SSL.
Yes, and if you are using something else, then use it - other ways of making Bitcoin transactions aren't going away. (although some poorly-written wallet software and Bitcoin libraries still haven't implemented P2SH addresses, which makes those other ways a bit inconvenient at times)
Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.
The enemy of better is perfect.
The enemy of better is perfect.
Sure but I would not use SSL for anything I really cared about (if it really mattered I would trust GPG).
I think the payment protocol idea itself is fine but we do need to have our eyes wide open when it comes to SSL.
I think anything that Google (MS or any other such company) suggests would not be acceptable by anyone (apart from those that of course work for Google, MS, etc.).
We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.
We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.
Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.
The enemy of better is perfect.
I think anything that Google (MS or any other such company) suggests would not be acceptable by anyone (apart from those that of course work for Google, MS, etc.).
We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.
We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.
There isn't any root key in the X.509 PKI.
Each CA has a private key that can be used to create certificates. If a government were to steal that key they could currently make bogus certs as if they were that CA, but that's being fixed via the certificate transparency effort. Although the government could still make bogus certs, they'd have to do so in a visible and public way which eliminates the value of doing so tremendously.
CT is a lot of work and a big upgrade, but it's being funded by Google and will be implemented in Chrome. At least one CA already signed up, even though the code isn't even finished yet.
Each CA has a private key that can be used to create certificates. If a government were to steal that key they could currently make bogus certs as if they were that CA, but that's being fixed via the certificate transparency effort. Although the government could still make bogus certs, they'd have to do so in a visible and public way which eliminates the value of doing so tremendously.
CT is a lot of work and a big upgrade, but it's being funded by Google and will be implemented in Chrome. At least one CA already signed up, even though the code isn't even finished yet.
In fact I cover this in my new payment protocol FAQ:
https://bitcointalksearch.org/topic/faq-on-the-payment-protocol-300809
https://bitcointalksearch.org/topic/faq-on-the-payment-protocol-300809
Thanks Mike. You posted that shortly after I raised my question. Good read though. I guess the part that I think you could go into more, is if, NSA has access to the root key, how does that effect Bitcoin's implementation of invoicing? Would that give them enough authority to spoof an invoice request? They wouldn't have access to any keys to make a transaction, but they could potentially be that MITM attack, no?
In fact I cover this in my new payment protocol FAQ:
https://bitcointalksearch.org/topic/faq-on-the-payment-protocol-300809
https://bitcointalksearch.org/topic/faq-on-the-payment-protocol-300809
Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?
While no guarantee, the entire process by which the DNSSEC root authority was signed was filmed and is publicly available: http://www.youtube.com/watch?v=b9j-sfP9GUU
There's reams of documentation and video publicly available on ICANN's site, although that's still only the root keys, not the registrar keys.
Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?
That has been a concern since before day 1.
The problem is that despite SSL's many, many, many flaws, it is still vastly superior to everything else.
Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?
Is my understanding correct that using the "payment protocol" will give away my IP address to the merchant?
No, not if you use Tor.
Tor (or i2p or some other anonymizing proxy solution) is the only way to keep online merchants from figuring out your IP. After all, if you browse to their website without Tor, then your IP is sitting right there in their web server logs.
Is my understanding correct that using the "payment protocol" will give away my IP address to the merchant?
No, not if you use Tor.
Tor (or i2p or some other anonymizing proxy solution) is the only way to keep online merchants from figuring out your IP. After all, if you browse to their website without Tor, then your IP is sitting right there in their web server logs.
Is my understanding correct that using the "payment protocol" will give away my IP address to the merchant?
I had an idea last fall for reforming the PGP web of trust into a general distributed identity system that would actually be easy and enjoyable for the average person to participate in, but I dropped it to focus on bitcoin...
Edit: http://bitcoinism.blogspot.com/2013/09/building-pgp-web-of-trust-that-people.html
Edit: http://bitcoinism.blogspot.com/2013/09/building-pgp-web-of-trust-that-people.html
You could have a merchant phone you and verify the payment address verbally, yes, but that assumes the criminals can't impersonate the merchant.
The root problem here is really hard - two parties who don't know each other and have never met want to communicate securely. The only thing the buyer knows is some fragment of an identity they {heard from a friend, found in a link, saw on a subway poster, etc}. Nobody knows a way to do this which doesn't involve some trusted third party issuing compact, unique, human readable identities.
The root problem here is really hard - two parties who don't know each other and have never met want to communicate securely. The only thing the buyer knows is some fragment of an identity they {heard from a friend, found in a link, saw on a subway poster, etc}. Nobody knows a way to do this which doesn't involve some trusted third party issuing compact, unique, human readable identities.
It seems like it should be possible to use SMS messages as an out of band method for verifying key fingerprints, although since even caller ID can be spoofed I'm not sure how to make it work in the presence of an adversary who can modify web traffic between the customer and the merchant (to give one or the other an incorrect phone number).
Perhaps merchants could publish verification phone numbers in dead tree publications. Prospective customer could text that number to get a code and then verify that code matches what they get through the web site.
It means that a potential attacker must be able to intercept and modify SMS traffic as well as Internet traffic in order to mount a successful attack.
Going through all that trouble might be worth it if it only had to be done once, such as the initial exchange of BIP32 public keys, especially if there was some way to automate the process using a smartphone app.
Perhaps merchants could publish verification phone numbers in dead tree publications. Prospective customer could text that number to get a code and then verify that code matches what they get through the web site.
It means that a potential attacker must be able to intercept and modify SMS traffic as well as Internet traffic in order to mount a successful attack.
Going through all that trouble might be worth it if it only had to be done once, such as the initial exchange of BIP32 public keys, especially if there was some way to automate the process using a smartphone app.
Jump to: