Lightweight ID verification for payment protocol v1.1

[Mike Hearn]

Yeah, as is often the way, with enough discussion it turns out people's ideas are not so far apart as it may first seem

The primary reason I'm interested in simple pseudo-CAs for sites like localbitcoins or reddit right now is that lots of code for X.509 stuff has already been written. In particular, web browsers know how to create private keys and install certs, then it's easy to grab them from wallet apps and use them. It may be possible to do the same with PGP but if so I haven't seen it in action. Also I can imagine what the code looks like and it's not much work.

I think a wallet dedicated to people who want to explore more complicated trust management would be an interesting project. If the UI can be proven to be easy, the ideas would spread to other wallets naturally with time.

[Carlton Banks]

I think a wallet dedicated to people who want to explore more complicated trust management would be an interesting project. If the UI can be proven to be easy, the ideas would spread to other wallets naturally with time.

"More complicated" is the means, not the end goal. PGP provides a better quality of trust hierarchies, it's not deliberately over complicated to confer some superficial or impressionistic level of identity confirmation.

In my mind, this best fits the ethos of Armory's uber-security model of development, but it may not fit that team's (already) busy roadmap (or their ideals). This sort of thing requires a well thought out implementation, as it will never catch on to the extent of becoming a standardised wallet technology without a design that's simple, yet powerful, yet usable, yet robust. Perhaps a WoT specific wallet might be the best option to satisfy those considerations, but I'd love for someone from the pre-existing wallets to take it on.


And to look from another angle, I really don't think SSL CA is good enough if you're buying, say, land, property, or some huge contract for outfitting an industrial facility or a commercial complex. Payments as a part of those sorts of contracts can be practicably insured in the legacy financial system, but I'm not sure how well such a model works in BTC. The extent to which these types of payment scenarios will be needed will only increase as time goes on. With luxury seaside mansions and supercars being marketed and purchased for bitcoin nowadays, it's only a matter of time before the pre-2011 bitcoin nouveaux riche will be demanding a better class of solution.

There should at least be some long term thought dedicated to providing a solution for those payments on the "largest" end of the scale, something that is attractive because it can be done without third-parties (for cost efficiency), and with negligible (or less) risk from subverting the verification of payment identities. I just can't see the suppliers to a big housing project settling up in an onsite mobile office using nothing but naked public keys, or CA verified pubkeys for that matter. The risk of losing money of that sort of magnitude just cannot be absorbed into any cost-of-business.

[piotr_n]

Right.
And that's development and technical discussion - really?
Because it sounds just like I was on some extremely boring presentation and all I wanted was to get out of there.

How is it even possible that a professional developers says that not writing a new code is good?
He must be at least two levels higher - only out there they don't give shit what the code does

[pera]

PLEASE STOP USING X.509

Implementing BIP 70 means centralizing part of Bitcoin's infrastructure by using an archaic protocol/specification full of patches (or "extensions") to try to make it look better... just don't do it, it would be an epic failure for bitcoin

In my opinion there are a lot of much more important things to improve before something like BIP 70, but if you really want it then at least do something like Convergence, or implement a distributed WoT with a more transparent/easier key signing.

[Mike Hearn]

"Just implement a better WoT" is easy to say, hard to do. You first.

Convergence is not a bad idea, but it is specific to checking ownership of DNS. CA's do more than just domain names.

[TheButterZone]

Is "Just implement certs" hard to say, easy to do then? Because it seems as if you're going to be arguing for it until you are blue in the face because you're the last person on earth, after everyone else has died from asphyxia.

[Peter Todd]

"Just implement a better WoT" is easy to say, hard to do. You first.

Convergence is not a bad idea, but it is specific to checking ownership of DNS. CA's do more than just domain names.

"Do more" - do what exactly? As you said above, bitcointalk got compromised because "bitcointalk lost control of its domain name, which is its identity, and the hacker was able to verify ownership of that identity." and "No CA had leaked its private key or done anything wrong" in that case. The same applies to user-specific certificates, like those silly email-based ones you promoted above that are trivially gotten by anyone who hacks into your email, or by extension, computer. Frankly you'd be almost better off just sticking with stealth addresses and Trust On First Use (TOFU) mechanisms - it'd be more honest about what actual security is being offered.

Or you can just a WoT mechanism and start with the same poor security, and improve it over time.

You know, what's nasty about this is how WoT mechanisms are an obvious competitor to the hierarchical CA system; good UI's can let Alice verify Bob's key with their mutual friend Charlie easily, and if systems like that ever catch on it's easy to imagine less profit in that business. Even just my proposed compromise with "pseudo-CA"'s based on multiple trusted/semi-trusted roots of trust is a serious competitor - it's much harder to be the "market leader" in payment verification if people naturally expect to cross-verify multiple sources. Obviously there's incentives to push hierarchical solutions from a commercial perspective.

[Mike Hearn]

"Do more" - do what exactly? As you said above, bitcointalk got compromised because "bitcointalk lost control of its domain name, which is its identity

Yes, and that's the tradeoff you make when you make your domain name your identity.

If BitcoinTalk was a real organisation or company, it could have got an EV cert and that would have been much harder for an attacker to duplicate. But it isn't. It's just a website. You get what you pay for.

Even just my proposed compromise with "pseudo-CA"'s based on multiple trusted/semi-trusted roots of trust is a serious competitor

I'm all for exploring new ideas, but reality check time: your proposed system doesn't exist and all prior attempts to make such ideas not suck have failed. PGP has been such a colossal failure that even people who should have been highly motivated to use it refused to do so; people like terrorists and investigative journalists whose lives were on the line.

In contrast the CA system has verified tens of millions of identities and is in use by over a billion people. You cannot make a bunch of forum posts and claim to have created a serious competitor to it, sorry.

[Peter Todd]

"Do more" - do what exactly? As you said above, bitcointalk got compromised because "bitcointalk lost control of its domain name, which is its identity

Yes, and that's the tradeoff you make when you make your domain name your identity.

If BitcoinTalk was a real organisation or company, it could have got an EV cert and that would have been much harder for an attacker to duplicate. But it isn't. It's just a website. You get what you pay for.

You having gotten an EV cert doesn't protect you against some other CA issuing a non-EV cert and someone using that cert for malicious purposes. Again, we're talking about your proposal of "mini-roots" of trust, and I've shown quite clearly why it leaves users more vulnerable, not less.

Of course, if you were to be getting involved in a business trying to sell end-users certs that'd be another matter... What's Circle doing in this space anyway?

Even just my proposed compromise with "pseudo-CA"'s based on multiple trusted/semi-trusted roots of trust is a serious competitor

I'm all for exploring new ideas, but reality check time: your proposed system doesn't exist

Neither does yours, and all prior attempts to make it exist have gone nowhere.

and all prior attempts to make such ideas not suck have failed. PGP has been such a colossal failure that even people who should have been highly motivated to use it refused to do so; people like terrorists and investigative journalists whose lives were on the line.

In contrast the CA system has verified tens of millions of identities and is in use by over a billion people. You cannot make a bunch of forum posts and claim to have created a serious competitor to it, sorry.

What you really mean is that person-to-person crypto is a colossal failure among average people. The CA system gets used semi-effectively for websites, but for identifying people, hardly at all. OpenPGP doesn't get used for websites, but among security conscious parts of the tech community it gets used, and as I showed above in my Tor example it's effective among that knowledgeable crowd.

It's really telling that in your example of terrorists and investigative journalists someone in either space saying "Hey! Here, use this S/MIME key with me to communicate!" would actually either get the response of either "Huh?" or if they're a bit more knowledgable "Um... why isn't he asking me to use that secure PGP thing? Am I being entrapped by a government agent?" And heck, for terrorists specifically, using electronics communications at all would get that response... you might want to ask yourself how the security, or lack thereof, of in-browser-cert-stores is going to play out among real end-users with compromised machines. There's a lot to be said for the much simpler Trust On First Use principle Adam Back has been pushing lately. Part of the idea behind stealth addresses is to make TOFU-style usage easier without sacrificing privacy if ever you want to have your using peers cross-verify the addresses.

[piotr_n]

PGP based WOT called botcoin-otc, has been in the bitcoin world since November 2010.
Bitcoin-OTC is definitely much more trustworthy then any CA authority out there.
There is no way that Google can develop anything better than that, unless we first get to redefine "better".

Though, it is actually worth noticing that Mike doesn't even seem to have a PGP key, so I totally understand his resistance against using this system.
@Mike, is it true that Google has banned using PGP among the employees, or is it just that they haven't organized a PGP training for you, so how would you even know how to operate this archaic tool? If the latter then maybe you can still put it into your personal development agenda for the next year - we all would have benefited from it

[TruckStyling]

I have a question about this proposal. Who is gonna run the CA?

Who is gonna decide "Ok, you are really overstock.com, you get a cert." vs. "No, you are just a scammer, pretending to be overstock.com, you get no cert."?

[pera]

"Just implement a better WoT" is easy to say, hard to do. You first.

Convergence is not a bad idea, but it is specific to checking ownership of DNS. CA's do more than just domain names.

I am not sure if you were quoting me in any form... I never said it would be easy, what I did say is that no part of Bitcoin's protocol (except well, the bootstrapping process) should be based on centralized protocols/infrastructures. Also, in my opinion OpenPGP WoT is actually pretty good (especially with SKS) and there already is at least one project implementing cert validation through it (ie Monkeysphere).

And maybe my memory is failing really bad but I was talking about Moxie's Convergence, that is nothing to do with DNS.

[justusranvier]

The PGP model has been around for decades and is a practical failure. Attempting to resurrect it is a waste of time. The vast majority of people cannot be bothered with in depth key trust  management, not even the minority who understand how to do it.

But if you want to continue living in a fantasy land where ordinary Bitcoin users are all going to start configuring their web of trust by hand, go ahead!

The underlying protocol for the PGP web of trust is just fine. The UI/UX needs to be completely scrapped and replaced with something normal people can use: http://bitcoinism.blogspot.com/2013/09/building-pgp-web-of-trust-that-people.html

[Quora]

The PGP model has been around for decades and is a practical failure. Attempting to resurrect it is a waste of time. The vast majority of people cannot be bothered with in depth key trust  management, not even the minority who understand how to do it.

But if you want to continue living in a fantasy land where ordinary Bitcoin users are all going to start configuring their web of trust by hand, go ahead!

The underlying protocol for the PGP web of trust is just fine. The UI/UX needs to be completely scrapped and replaced with something normal people can use: http://bitcoinism.blogspot.com/2013/09/building-pgp-web-of-trust-that-people.html

But isn't Mailvelope great? I just added it to Chrome (for Gmail), it's amazingly simple to set up, use and it seems it's cross-compatible. Before that I only tried Kryptokit but the GPG public key wasn't compatible with recipient's PGP one I guess (Kryptokit imported the PGP public key, everything was great, the email was sent but it wasn't received). I found out that "PGP is not really OpenPGP (and GPG etc.?) aware" because "they use different encryption algorithms due to PGP patent restrictions/business reasons."

[genjix]

lol mike hearn wanted to use passports for auth between bitcoin nodes. what a newb.

[luv2drnkbr]

Mike is right that if a openpgp wot system is too difficult or annoying, nobody will use it.  But Peter is right that is 100% needs to be available as an option for the people who wish to not use centralized entities for their certificate validation.  Peter's compromise (below) is clearly the only correct option.