This whole PKI discussion misses the bigger issue: the first users of the payment protocol are highly likely to be websites, which means you already depend on SSL security and thus the SSL PKI system. In that circumstance putting all your eggs in one (flawed) basket is perfectly reasonable - better PKI's can be developed later.
Anyway the payment protocol has support for adding additional PKI systems in the future.
Topic: Invoices/Payments/Receipts proposal discussion - page 14. (Read 24728 times)
That may well all be true, but it's unclear what the better alternative is. The next best PKI would seem to be DNSSEC which is basically "SSL PKI but with one CA per country or TLD" .... it solves the problem of incompetent CA's by having fewer of them. Hardly an excellent solution. Recall the world started out with just one SSL CA and people complained there wasn't enough competition.
We need something where I can walk into a room holding a beer, sit down and tell my buddy "hey check out bitcoinmagazine.com". Then they go there and make a payment and it says "bitcoinmagazine.com" or "Bitcoin Publishing Inc" or whatever on the screen of their Trezor or other device. We know how to do that with the SSL PKI, we can sort of see how to do that with DNSSEC (though it's a lot more work) and I'm not sure how to do it with anything else. It's a research problem. Perhaps my phone could remember the keys that were used when I visited bitcoinmagazine.com and ambiently broadcast them to the room when I walk in. Then my buddys phone can learn the certs/keys from me at the same time as we're conversing. Anyway it's a hard problem.
We need something where I can walk into a room holding a beer, sit down and tell my buddy "hey check out bitcoinmagazine.com". Then they go there and make a payment and it says "bitcoinmagazine.com" or "Bitcoin Publishing Inc" or whatever on the screen of their Trezor or other device. We know how to do that with the SSL PKI, we can sort of see how to do that with DNSSEC (though it's a lot more work) and I'm not sure how to do it with anything else. It's a research problem. Perhaps my phone could remember the keys that were used when I visited bitcoinmagazine.com and ambiently broadcast them to the room when I walk in. Then my buddys phone can learn the certs/keys from me at the same time as we're conversing. Anyway it's a hard problem.
In my opinion:
The PKI issue under discussion here is absolutely critical. I understand that the effort aims to provide X.509/CA certificates as one option for securing the messages under discussion as a modular plugin to an API which would, at the outset, also support "unsigned plain" types. The work embodied in Gavin's "pseudo-spec" looks to me like a big chunk of solid research that will contribute to Bitcoin's flourishing.
But the thinking that leads to comments like this one from Mike worries me deeply:
The facts regarding the existing CA infrastructure, as pointed out by justusranvier above, are irrefutable, and his comment regarding fire extinguishers needs to be taken very seriously by anyone implementing crypto-centric software in the year 2013 and beyond. The CAs are broken beyond repair (if not by design, /tinfoil) and they are not going to be fixed. Implementing new "secured" payments messaging on top of a foundation that includes the public CAs is like building a castle out of counterfeit bricks: no matter the skill of the masons, the castle will fall.
At the moment, the core dev team, in considering this proposal, are acting as architects, engineers and masons. That's great: the puissance they've shown to date makes them masters of all three crafts. But to do the job to the fullest, the castle must protect the people who dwell inside it. And no matter the vision of the architect, the precision of the engineer or the skill of the mason, their work means worse than nothing if they elect to build the castle out of the same faulty bricks being used in That Other Kingdom of which We are All Well Aware. If the barbarian horde which breaches the ramparts does not slay them, surely the survivors of the short-lived siege will, in retribution for their criminal negligence.
Lots of people have and use shitty bricks. Building out of shitty bricks is easy. The road to perdition is easy, too.
The PKI issue under discussion here is absolutely critical. I understand that the effort aims to provide X.509/CA certificates as one option for securing the messages under discussion as a modular plugin to an API which would, at the outset, also support "unsigned plain" types. The work embodied in Gavin's "pseudo-spec" looks to me like a big chunk of solid research that will contribute to Bitcoin's flourishing.
But the thinking that leads to comments like this one from Mike worries me deeply:
Quote
X.509 cert chains are flawed in many ways. They're being used in this spec for one reason and one reason only - lots and lots and lots of people already have them, they're easy to get, and they assert to an identity (normally a domain name). Also, the code to do the signing and verification is simple (I sent Gavin an example) and can be implemented with OpenSSL in about a page of code.
The facts regarding the existing CA infrastructure, as pointed out by justusranvier above, are irrefutable, and his comment regarding fire extinguishers needs to be taken very seriously by anyone implementing crypto-centric software in the year 2013 and beyond. The CAs are broken beyond repair (if not by design, /tinfoil) and they are not going to be fixed. Implementing new "secured" payments messaging on top of a foundation that includes the public CAs is like building a castle out of counterfeit bricks: no matter the skill of the masons, the castle will fall.
At the moment, the core dev team, in considering this proposal, are acting as architects, engineers and masons. That's great: the puissance they've shown to date makes them masters of all three crafts. But to do the job to the fullest, the castle must protect the people who dwell inside it. And no matter the vision of the architect, the precision of the engineer or the skill of the mason, their work means worse than nothing if they elect to build the castle out of the same faulty bricks being used in That Other Kingdom of which We are All Well Aware. If the barbarian horde which breaches the ramparts does not slay them, surely the survivors of the short-lived siege will, in retribution for their criminal negligence.
Lots of people have and use shitty bricks. Building out of shitty bricks is easy. The road to perdition is easy, too.
I agree this little communication with customer is great, but maybe call it Acknowledgement ...
Yeah, that's reasonable. Remember that a receipt is a signed invoice + a confirmed transaction (proof of payment). That is, you cannot have a receipt without blocks. Having a message in the protocol also called Receipt when it's actually an acknowledgement could be confusing indeed.
Quote
Can GPG support be written in the standard, also as an optional feature?
Not at the moment, for the reasons that should be apparent from the previous posts. Just saying "GPG support" is way too vague to be actionable. Figuring out how a web of trust can be used in a payment protocol is what I'd call a research level problem - somebody needs to go away and figure out all the messy details, maybe build a proof of concept (as I did for X.509 support), and then write a BIP to show how to extend the payment protocol.
Even if there's not a developed web-of-trust system for GPG available, technically-savvy people still use GPG successfully. I agree that such users should have the option to exchange/verify public keys out of band, to their own comfort level, and rely on that for signing invoices. As long as all parties agree.
I agree this little communication with customer is great, but maybe call it Acknowledgement ...
Yeah, that's reasonable. Remember that a receipt is a signed invoice + a confirmed transaction (proof of payment). That is, you cannot have a receipt without blocks. Having a message in the protocol also called Receipt when it's actually an acknowledgement could be confusing indeed.
Quote
Can GPG support be written in the standard, also as an optional feature?
Not at the moment, for the reasons that should be apparent from the previous posts. Just saying "GPG support" is way too vague to be actionable. Figuring out how a web of trust can be used in a payment protocol is what I'd call a research level problem - somebody needs to go away and figure out all the messy details, maybe build a proof of concept (as I did for X.509 support), and then write a BIP to show how to extend the payment protocol.
+1 for this thread, it finally nudged me to purchase a membership in the Bitcoin Foundation (I was just taking my sweet time till now).
Stuff like this is why Bitcoin will remain more relevant than any other alt chain, and why Gavin deserves a paycheck.
While other alt chains are exploring interesting yet esoteric concepts, we've seen little true innovation there (not to dismiss Namecoin & Proof of Stake, both of which might turn out to be real players later on).
Gavin and others in Bitcoin are working on the gray little details that are essential to building a successful payment system, not just building cool toys.
Stuff like this is why Bitcoin will remain more relevant than any other alt chain, and why Gavin deserves a paycheck.
While other alt chains are exploring interesting yet esoteric concepts, we've seen little true innovation there (not to dismiss Namecoin & Proof of Stake, both of which might turn out to be real players later on).
Gavin and others in Bitcoin are working on the gray little details that are essential to building a successful payment system, not just building cool toys.
As Gavin already mentioned, the X.509 support is optional. You can create unsigned invoices. And in future, signed invoices that don't use X.509 if we can find some reasonable system.
Can GPG support be written in the standard, also as an optional feature?
I would urge you to return a receipt with a memo that says:
"your order will be shipped as soon as your payment has three confirmations."
Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.
"your order will be shipped as soon as your payment has three confirmations."
Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.
I agree this little communication with customer is great, but maybe call it Acknowledgement ...
Receipt has got a flaw. As a merchant I won't be sending receipts of funds without any confirmations. FYI 
I would urge you to return a receipt with a memo that says:
"your order will be shipped as soon as your payment has three confirmations."
Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.
Receipt has got a flaw. As a merchant I won't be sending receipts of funds without any confirmations. FYI
The CA system isn't perfect, but those who succeed in breaking it are usually high profile (like Mike Hearn was saying: state-sponsored, etc), and they're not going to waste their time stealing the $42 I paid BitBrew for some coffee.
As Gavin already mentioned, the X.509 support is optional. You can create unsigned invoices. And in future, signed invoices that don't use X.509 if we can find some reasonable system.
Let's not stab this baby through the heart by using X.509. This would make it impossible to do pseudonymous invoicing and it's also, well, thoroughly broken (DigiNotar anyone?).
It might be worth supporting (or perhaps even demanding) an OCSP stapling-like mechanism for certificate revocation checks. This would place the burden of OCSP querying on the merchant, who is typically better equipped to perform such queries. It also scales better, is potentially more reliable and does not leak information to a 3rd party.
SSL is allowed to suck because it tends to protect nothing important. In the real world, there is no such thing as an irreversible transaction. A credit card number that gets intercepted these days pretty much means you are going to spend a very annoying 3 minutes on the phone with the fraud department of your bank. Do you still look for the padlock icon before typing in your credit card number? I sure don't. Online stores use SSL because Visa and Mastercard make them use SSL, and the processors insist on SSL because it reduces fraud claims. You (the user) are never a factor.
My complaints with the SSL system are:
1. There are tools that can mitigate the security/fraud problems, but no one takes them seriously. Turn on strict OCSP checking in your browser if you want to see for your self.
2. The CAs actively participate in industrial MITM snooping operations. Your corporate IT department probably has a box that uses a wildcard cert issued by a legitimate CA to inspect all of your SSL traffic.
3. Race to the bottom! The whole point of having CAs is that they verify things, which is what you pay them for. Over the years, they've all decided to stop doing their job and just take your money for nothing. It got so bad that marketing had to step in and invent a whole new class of SSL certs (EV) where the CA actually does what it was supposed to have been doing all along.
That said, SSL is here and everywhere, and as badly as it sucks, every other option sucks worse. It really is the logical choice for this. Just remember, there is no chargeback in bitcoin. If you have a payment request for more money than you can afford to lose, think real hard about how much you really trust that cert. Odds are very good that no human has ever looked at any part of it before.
My complaints with the SSL system are:
1. There are tools that can mitigate the security/fraud problems, but no one takes them seriously. Turn on strict OCSP checking in your browser if you want to see for your self.
2. The CAs actively participate in industrial MITM snooping operations. Your corporate IT department probably has a box that uses a wildcard cert issued by a legitimate CA to inspect all of your SSL traffic.
3. Race to the bottom! The whole point of having CAs is that they verify things, which is what you pay them for. Over the years, they've all decided to stop doing their job and just take your money for nothing. It got so bad that marketing had to step in and invent a whole new class of SSL certs (EV) where the CA actually does what it was supposed to have been doing all along.
That said, SSL is here and everywhere, and as badly as it sucks, every other option sucks worse. It really is the logical choice for this. Just remember, there is no chargeback in bitcoin. If you have a payment request for more money than you can afford to lose, think real hard about how much you really trust that cert. Odds are very good that no human has ever looked at any part of it before.
I thought I might point out that I have successfully made deals for Bitcoins using signed payment addresses and existing PKI infrastructure as long ago as early 2011, using a methodology that is not only mind-numbingly simple for even average users, but using a contract form that is arguably admissible in today's courts: digitally signed PDF files.
https://bitcointalksearch.org/topic/trusting-sellers-of-large-amounts-of-bitcoins-3170
A significant drawback is cost, but the subject proposal already contemplates the purchase of keys from a CA so it's a non-issue, especially for any serious business endeavor, we're talking a few hundred bucks. This one uses a more secure approach than the hodge podge of SSL CA's: the policy enforced on the Adobe Acrobat document-signing PKI is that all keys must be contained in HSM's (hardware security modules), user's aren't even allowed to know their own private keys. The price of an Acrobat signing cert includes a keychain sized USB HSM with no private key. The module generates its own private key, after the user has received it, and the setup process makes web calls to the provider to generate and install a corresponding certificate into the module.
By bringing this up, I wish to be seen as suggesting that a suitable solution to many such problems might already exist, and not in any way to suggest "stop what you're doing, this problem is solved". Clearly this solution only works when a PDF file is the means in which an invoice is presented to the customer, and only when it's generated in an environment where the required HSM can be used.
My key happens to be a Rainbow iKey 2032 - something already generically available on the market and not proprietary to Adobe. In fact, I would be willing to bet that it could be coaxed into signing anything interacting with the proper API given the user's passphrase to unlock the module, and on pretty much any platform. The way it is seen by the computer, it amounts to a smart card reader with a smart card effectively soldered in it.
It's also pretty apparent that it would be desirable for the Bitcoin client to know you're really paying the right person, which isn't feasible in any clean manner from a PDF file (though not impossible - especially if there were such thing as a payment address meta tag inside the PDF file that a bitcoin client could easily pick out after hashing the file and confirming it's properly signed).
https://bitcointalksearch.org/topic/trusting-sellers-of-large-amounts-of-bitcoins-3170
A significant drawback is cost, but the subject proposal already contemplates the purchase of keys from a CA so it's a non-issue, especially for any serious business endeavor, we're talking a few hundred bucks. This one uses a more secure approach than the hodge podge of SSL CA's: the policy enforced on the Adobe Acrobat document-signing PKI is that all keys must be contained in HSM's (hardware security modules), user's aren't even allowed to know their own private keys. The price of an Acrobat signing cert includes a keychain sized USB HSM with no private key. The module generates its own private key, after the user has received it, and the setup process makes web calls to the provider to generate and install a corresponding certificate into the module.
By bringing this up, I wish to be seen as suggesting that a suitable solution to many such problems might already exist, and not in any way to suggest "stop what you're doing, this problem is solved". Clearly this solution only works when a PDF file is the means in which an invoice is presented to the customer, and only when it's generated in an environment where the required HSM can be used.
My key happens to be a Rainbow iKey 2032 - something already generically available on the market and not proprietary to Adobe. In fact, I would be willing to bet that it could be coaxed into signing anything interacting with the proper API given the user's passphrase to unlock the module, and on pretty much any platform. The way it is seen by the computer, it amounts to a smart card reader with a smart card effectively soldered in it.
It's also pretty apparent that it would be desirable for the Bitcoin client to know you're really paying the right person, which isn't feasible in any clean manner from a PDF file (though not impossible - especially if there were such thing as a payment address meta tag inside the PDF file that a bitcoin client could easily pick out after hashing the file and confirming it's properly signed).
Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.
It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities.
...and then people set up fake merchant identities and countless fake customer identities, and bump up their own trust ratings as high as they want before each scam. The best way to prevent this from happening is to elect third parties that are trusted by lots of people, to check identities before letting them into the system... oh wait, I just described the CA system...
And if you allow me to abstract what you're describing here: a system of trusted authorities that check the veracity of identities.... What are electronic and paper payments if not "identities", or at least having an identifier to distinguish between individual instances is fundamental to a working system. And so, you've also just described (abstractly) the fiat money system.
And here we are again back at the beginning of the argument... except I think the critical mass argument has merit. With enough people using the system, and enough time/resources to reliably discover people abusing it, it can only become stronger as adoption and use increase. The critical mass required is a problem.... unless you can piggy back on the userbase of an existing, growing system that could make good use of a trust credit system (can't seem to think of any obvious candidates myself
) If it wasn't for PKI, e-commerce would be very dangerous, so thank goodness for it. It means I can buy a DVD off the internet and know I'm paying to the right person and not a man-in-the-middle.
If another system worked better, we'd be using that, but since there is none we do not. And if you do not trust a particular CA, then you can remove it from web browsers: http://techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-certificate-in-chrome-firefox-and-ie/
A bitcoin system should also allow users to configure trusted CAs.
If another system worked better, we'd be using that, but since there is none we do not. And if you do not trust a particular CA, then you can remove it from web browsers: http://techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-certificate-in-chrome-firefox-and-ie/
A bitcoin system should also allow users to configure trusted CAs.
Not talking about encrypting transactions, I'm referring to the specific case of identities verified by CA's. Agree entirely to what you said above, it's kind of self evident
Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.
It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities.
...and then people set up fake merchant identities and countless fake customer identities, and bump up their own trust ratings as high as they want before each scam. The only way to prevent this from happening is to elect third parties that are trusted by lots of people, to check identities before letting them into the system... oh wait, I just described the CA system...
I agree with this analysis under circumstances where the system isn't near-ubiquitous, but in real life, when a multiple fake identity scammer themself becomes identified (with their actual real world identity), then their own personal trust capital will become appropriately diminished (people that know them will revoke the trust they have invested in them, so not quite a traditional commodity by any stretch). And so with a given amount of critical mass, the system would self-regulate. And imagine how "wealthy" eccentric old widowers suddenly become? Everyone's encountered the people you can trust the most in life, and these people would get direct, quantifiable recognition for it. How about that?
If it wasn't for PKI, e-commerce would be very dangerous, so thank goodness for it. It means I can buy a DVD off the internet and know I'm paying to the right person and not a man-in-the-middle.
If another system worked better, we'd be using that, but since there is none we do not. And if you do not trust a particular CA, then you can remove it from web browsers: http://techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-certificate-in-chrome-firefox-and-ie/
A bitcoin system should also allow users to configure trusted CAs.
If another system worked better, we'd be using that, but since there is none we do not. And if you do not trust a particular CA, then you can remove it from web browsers: http://techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-certificate-in-chrome-firefox-and-ie/
A bitcoin system should also allow users to configure trusted CAs.
Jump to: