Bitcoin Forum

Summary: I propose that each wallet developer include a custom root cert in the set of roots they accept for the payment protocol and that we establish our own mini PKI / X.509 extensions for the Bitcoin early adopter community.

---

Background

bitcoinj 0.11 will soon be ready for release. Just before we release it I'm planning to merge some initial support for the BIP 70 payment protocol, though it won't be very sophisticated. In particular it won't support generating payment requests, only consuming them. But ... after a bit more work to do such as adding support to the wallet-tool command line app (the bitcoinj equivalent of sx) and ensuring that we can load the key store on every supported platform, we'll be ready.

One of the criticisms levelled at the design of the payment protocol is that it uses the PKI, a system of certificate authorities that validate ownership of "identities" (arbitrary small pieces of text, actually) and charge money for the privilege.

These days you can get free certificates for email addresses and domain names. Comodo has a very simple and easy to use way to get them based on HTML5 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen): you just provide your email address and name, which isn't validated so it can be fake, and then your browser generates the private key locally and stores it. Then you click the verification link delivered to your email address, and the process completes with the fully signed cert being installed by the browser into your operating system keystore. It's as easy as signing up for a website and after doing that, if you use a desktop mail client like Apple Mail.app, Thunderbird etc then you can sign your mails and receive encrypted mails from other people without PGP. The same certificate can be used to sign payment requests. Try it out, it won't take long. The keygen tag actually works for any website.

Issues with the current system

Although getting an email address or domain cert is easy and free these days, there are still some inadequacies here:

• There are over a hundred CA's, of which only two issue free certs (Comodo and StartCom). Others also did in the past but they tended to get bought by Symantec which then discontinued the free services. Free is important to get wide usage.
• Often people communicate using identities which are not email addresses, like forum/reddit handles/social network profiles/IM network handles/etc. CA's do not issue certificates for these kinds of identity.
• Even for a free Comodo email address cert, you have to sign up via a web browser. There's no API to do it from apps.

What stops someone simply setting up a new CA as part of the existing system and adding all these features? In theory, nothing. In practice, a lot. Existing users of the PKI are things like operating systems and web browsers, all of which get distributed to hundreds of millions or even billions of people. Often, CA certs are put inside embedded devices like cameras or TV sets. Update cycles are slow. This makes the cost of a leaked root private key astronomically large - potentially billions of devices must be updated and millions of identities revoked and reissued.

Because the PKI system is so large, and the cost of root cert revocation so huge, browser and OS makers require a high degree of professionalism before they'll consider adding you as a root CA. Reducing risk means expensive measures are taken to preserve security:

• Root keys are stored offline and used only to sign intermediate certificates. This is a bit like a "cold wallet".
• Intermediate keys are stored in dedicated tamper-proof hardware security modules.
• CAs must allow users to mark their certs as revoked so when users get hacked or lose their private keys, people automatically stop trusting those keys. That means servers have to be funded and run to serve real-time revocation data via OCSP. The bandwidth and CPU's for this is a cost of business.
• Employees must be background checked and business processes put in place to stop rogue employees issuing fake certs to themselves.
• All the above is too hard for Mozilla/Chrome/Apple/Microsoft/Debian/etc to check themselves, so they outsource verification to professional auditing firms, who of course don't work for free.
• Because all the above is costly, CAs tend to charge for their certificates, which in turn means people expect tech support and other expensive things, raising the cost still further.

The above requirements are just a flavour of what it takes to get into the Mozilla or Windows/MacOS root cert stores. That's why you can't do it, and if you did, you'd end up charging money and selling out to Symantec as well.

An alternative

Is all the above really necessary for every use case? Sometimes the answer is definitely yes - if you see your Trezor say, "Pay 5 BTC to Overstock, Inc of Salt Lake City, USA" you want that statement to actually be meaningful and hard to forge, and Overstock can easily swallow the cost of paying someone to verify who they are. The PKI and existing CAs get us that functionality.

On the other hand, for a message like "Pay 0.5 BTC to bitcointalk user satoshi" you don't really need that level of security. You know that bitcointalk is just a web forum that gets hacked from time to time and that forum handles don't mean much, but you're probably OK with that for small purchases. And if all your communication was on this forum with a particular user handle, then seeing an email address or a real name doesn't actually help because that's not the identity you're expecting and have built trust in.

There is no way in hell that Mozilla is going to accept a root authority run by Theymos for a couple of reasons:  bitcointalk has a terrible security track record so it'd be very likely to get revoked, and forum names don't mean anything to a web browser anyway. But nothing stops wallet app authors from trusting Theymos for this purpose.

What does this mean in practice? Let's say that when bitcoinj 0.11 rolls around it checks all the OS provided root certs, AND also a set of custom root certs for various providers that the Bitcoin community uses a lot like this forum, or reddit, or the Bitcoin Foundation, etc. A final root cert owned by the wallet author (or possibly me in this case) can also be added so new providers can come online without waiting for wallet users to upgrade.

These certificates are regular X.509 certs but with a new extension field that indicates how subcerts should be displayed to the user, for instance:


Now when this forum issues someone a cert with CN=satoshi, wallet software knows to display it in the UI like this:


... same for reddit, #bitcoin-otc, localbitcoins, etc.

What does this look like for the user? Try it out and see (https://openweb.or.kr/html5/e_keygen.php). For a browser like Chrome or Safari, when the browser installs the cert it does so into a global keystore that is accessible to wallet apps too, so that's all that's required to install it.

This would upgrade the security for many common payment scenarios without much cost. Of course the chances of hacks/screwups and global revocations are pretty high, but we're still a small community mostly made up of tech-savvy enthusiasts so we can tolerate that for now.

The nice thing about making minor extensions to X.509 rather than trying to support a second PKI is that we get to reuse all the infrastructure, software and protocols built to support the existing system. For instance, if the bitcointalk admins are handling people who get their accounts hacked and helping them restore access then they could also start running an OCSP server so any certificates issued during the time the account was hacked get automatically revoked. From the perspective of wallet devs and site admins it just requires reusing existing software, so it's a small amount of extra work.

<gmaxwell> go11111111111: Mike Hearn is a nice and smart guy. But he's also nearly a parody of himself with his constant recourse to centralization. I dunno, I haven't paid a lot of attention to anything he's said on privacy since he's generally been pretty hostile to it in the past.

We talked about exactly this kind of use-case at Dark Wallet hackathon, and quickly concluded that OpenPGP was fundamentally the right way to do it. (specifically with stealth addresses) Why? Because OpenPGP is built around a web-of-trust model rather than the strict hierarchy that X.509 assumes.

You're example of a bitcointalk-specific PKI is an excellent example of why this matters: I don't trust bitcointalk because they've been hacked multiple times. Nor do I or should I trust centralized certificate authorities that have been compromised - bitcointalk itself recently fell victim to a CA compromise. On the other hand between bitcointalk, bitcoin-otc, and hopefully some shortish PGP WoT path from me to the recipient I've got a reasonable assurance - much more assurance than if I'm trusting the centralized bitcointalk PKI system.

So don't repeat the mistakes of the past all over again by encouraging blind reliance on centralized PKI. Support OpenPGP first, and hack in whatever X.509 support you need to use X.509 PKI when available as secondary authentication. This isn't merchant websites we're talking about after all, this is individuals.

Of course, from a practical point of view... theymos: you wanna take on the risk of running some pseudo-PKI when you know the underlying X.509 tech and UI's around that encourages trusting it totally? I sure wouldn't given there's money involved.

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!

OK, that’s a bit unhelpful. Here’s a longer reply.

X.509v3 does actually allow for multiple signers of one certificate, which amounts to a more scalable version of the OpenPGP WoT. In practice this feature is rarely used because for any given identity, there’s usually one correct way to validate it and so having different entities repeatedly verify the same identity doesn’t really add much. For instance, you claim (wrongly) that bitcointalk.org was victim of a CA compromise. This isn’t correct. No CA had leaked its private key or done anything wrong - bitcointalk lost control of its domain name, which is its identity, and the hacker was able to verify ownership of that identity. You can’t easily separate such a situation from the domain name being genuinely transferred from one legitimate owner to the next - at least not without extra hassles, at which point you start getting into EV territory.

Let’s put it another way. Sometimes people suggest strengthening SSL by requiring sites to present cert chains up to more than one root authority, i.e. a web of trust model. These proposals are ignored because:

a) The outcome of the trust algorithm is either display the padlock or don’t. It’s a binary yes/no outcome because users have been trained to look for the padlock when typing in their password. They don’t have any deeper training than that. What does it mean in the user interface for a site to have one vs two trust chains? Display two padlocks? That would just confuse people.

b) The way identities are verified is standardised, it has to be otherwise the decision to trust a third party for the purposes of id verification is meaningless. If you can beat one authorities way of verifying identities, that means you can probably beat all of them. In the bitcointalk case having two CA’s verify the hackers ownership of the domain name instead of one wouldn’t have helped.

These issues are inherent to the web of trust concept. They aren’t something specific to PKIX vs OpenPGP.

In the case of a wallet, the outcome is also a binary yes/no decision. Do you display the string asserted by the signer, or not? More complicated output rapidly takes us into neckbeard territory. Questions a user would have to answer:

1) I see a single trust path to this identity. Is that OK or should I refuse to pay unless I get two? What if the counterparty claims they can't get two?

2) I see two trust paths to this identity. Does that mean anything or did both paths just duplicate the same work?

It might be possible to resolve these questions in very specific use cases, like if localbitcoins issued certs and then users could cross-sign each others certs when they met in person (like via a trading app - you wouldn’t expose what’s happening to the end user). Then wallets would have to find a meaningful way to explain what had happened. Maybe it could put this into the UI:

“Pay to localbitcoins.com user cooltrader, who has been met in person by localbitcoins user John Doe”

But if that second part wasn’t there, would you refuse to trade with cooltrader? Very hard to say, I don't know what I'd do in this situation.

The final problem is of course, when people talk about the “web of trust model” usually what they mean is “I hate the evil centralised certificate authorities”, implying that they’d rather their apps come with an empty key store and be manually filled up. But I don’t know anyone whose first action on installing an OS is to erase the system SSL cert store and replace it with their own, even though they could. Nobody does that because even though SSL wouldn’t technically break, in practice the number of trust decisions you’d have to make would render it impractical. That's the whole reason we outsource it.

Stop embarrassing yourself.

The only practical failure I see here is Mike Hearn being called a core bitcoin developer.
The fact that Google does not like PGP - it only makes us to want using it even more, though how a silly google puppet like you would even get to know that?

But sure, go ahead, man. Make sure to put more of your lame NSA sucking bullshit into the code, so people will stop using it even sooner - that's better for everyone.

Lets start with your original assumption:


Now for me, a tech-savvy enthusiast, is the PGP model a total failure? Lets see if I can verify the latest Tor download, from scratch with a clean PGP keyring, and my PGP key that I've done a bit of keysigning with:

pete@localhost:~$ gpg --verify tor-browser-linux32-3.5_en-US.tar.xz.asc
gpg: Signature made Tue 17 Dec 2013 03:41:09 PM EST
gpg:                using RSA key 416F061063FEE659
gpg: requesting key 416F061063FEE659 from hkp server keys.gnupg.net
gpg: key 416F061063FEE659: public key "Erinn Clark <erinn@torproject.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: Good signature from "Erinn Clark <erinn@torproject.org>"
gpg:                 aka "Erinn Clark <erinn@debian.org>"
gpg:                 aka "Erinn Clark <erinn@double-helix.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8738 A680 B84B 3031 A630  F2DB 416F 0610 63FE E659

Hmm... erinn@torproject.org! Well, that sounds reputable! Of course me being one of your "tech-savvy enthusiasts" I have some knowledge about WoT and know I need to find a path(s) (http://pgp.cs.uu.nl/paths/67E4FA04/to/63FEE659.html) between Erinn and me. I've done kinda well with my key signing, and by downloading six keys, three of whom are people I personally know, I have three independent paths to Erinn's key:

pete@localhost:~$ gpg --recv-key D8F056DD 94C09C7F C8FA5258 F2CF01A8 B0413BFA 70096AD1
gpg: requesting key D8F056DD from hkp server keys.gnupg.net
gpg: requesting key 94C09C7F from hkp server keys.gnupg.net
gpg: requesting key C8FA5258 from hkp server keys.gnupg.net
gpg: requesting key F2CF01A8 from hkp server keys.gnupg.net
gpg: requesting key B0413BFA from hkp server keys.gnupg.net
gpg: requesting key 70096AD1 from hkp server keys.gnupg.net
gpg: key 143C9F41D8F056DD: public key "Adam Back <adam@cypherspace.org>" imported
gpg: key DE7AAF6E94C09C7F: public key "Peter Palfrader" imported
gpg: key 438F770EC8FA5258: public key "Chris G. Davis <davis@lrtw.org>" imported
gpg: key 64A7C0A7F2CF01A8: public key "Bdale Garbee <bdale@gag.com>" imported
gpg: key AC859362B0413BFA: public key "Gregory Maxwell <greg@xiph.org>" imported
gpg: key 37E1C17570096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: key EC4B033C70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   3  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   3  signed:   4  trust: 3-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2016-10-18
gpg: Total number processed: 7
gpg:               imported: 7  (RSA: 2)

Of course, me being a tech-savvy enthusiast, I also know that PGP isn't magic and I need to tell OpenPGP how much I trust the identities associated with those keys:

pete@localhost:~$ gpg --update-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   3  trust: 0-, 0q, 0n, 0m, 0f, 1u
No trust value assigned to:
1024D/AC859362B0413BFA 1999-11-27
      "Gregory Maxwell <greg@xiph.org>"
  aka "Gregory Maxwell <gmaxwell@gmail.com>"
  aka "Gregory Maxwell <gmaxwell@mozilla.com>"
  aka "Gregory Maxwell <gmaxwell@wikimedia.org>"
  aka "[jpeg image of size 6019]"
 Primary key fingerprint: DE47 BC9E 6D2D A6B0 2DC6  10B1 AC85 9362 B041 3BFA

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  s = skip this key
  q = quit

Your decision? 4
1024D/37E1C17570096AD1 2005-12-28
      "Asheesh Laroia <asheesh@asheesh.org>"
  aka "Asheesh Laroia <ubuntu@asheesh.org>"
  aka "Asheesh Laroia <asheesh@openhatch.org>"
  aka "Asheesh Laroia <asheesh@creativecommons.org>"
 Primary key fingerprint: D004 36A9 0C4B D120 0202  0A3C 37E1 C175 7009 6AD1

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  s = skip this key
  q = quit

Your decision? 3

etc. etc. Being tech-savvy I know the marginal-vs-fully difference. Once I'm done I try the verify again:

pete@localhost:~$ gpg --verify tor-browser-linux32-3.5_en-US.tar.xz.asc
gpg: Signature made Tue 17 Dec 2013 03:41:09 PM EST
gpg:                using RSA key 416F061063FEE659
gpg: Good signature from "Erinn Clark <erinn@torproject.org>"
gpg:                 aka "Erinn Clark <erinn@debian.org>"
gpg:                 aka "Erinn Clark <erinn@double-helix.org>"


Great! Now I can go leak some NSA slides.

See, that's the thing: OpenPGP is too good. It provides way more robust security than 99% of the average user actually needs, so it's no surprise that the average user is going to think all those !@#$ steps - never mind the keysigning - was a gigantic pain in the ass and not do it. For them the CA certificates that the Tor project also uses are both good enough, and way easier to use. So of course they do. Then again, for those same users personal CA certificates have been a horrible failure too: Who the hell uses MIME outside of some tightly controlled corporate scenarios? Not many. Instead they use the much more practical, and much more centralized, DKIM email signatures that rely totally on your email provider. You yourself have "signed" bitcoinj releases with them.

But sometimes you need better security than that. Take the DNSSEC root keys: they're all verified by a stack of video-taped key ceremonies... and OpenPGP signatures. Or for a non-computer example, have you ever talked to a security professional about the procedures required to deliver large amounts of gold? Everything about when and where the shipment is going gets verified by multiple ways with procedures remarkably like the OpenPGP WoT, and for good reason: while unlike bitcoins you can undeliver gold, it's a procedure that can require armed men and violence.

You complain that users are going to balk at having "two green checkmarks" in their wallet software; I think they're going to be glad they had that the first time one of the checkmarks is bright red... and a day later they read on reddit about how a attack on some certificate authority let some Android wallet be scammed out of thousands of dollars worth of Bitcoin. Real-world attacks have a funny way of making people take security seriously, so lets not push blind reliance on centralized infrastructure any further and give those users the tools to stay safe.

Now, as for the practical aspects: You say that X.509 can have multi-authority authentication, which is true in theory, but as I say it's an architecture that just isn't very well suited to that, you're pushing a model of using it that ignores those capabilities, and on top of all that it can't do WoT authentication.

Equally though, the OpenPGP standard does allow for certificate authority style authentication. The PGP Global Directory Verified Key Service (https://keyserver.pgp.com) is one example, CAcert (http://www.cacert.org/) is another, and the standard itself has good mechanisms for defining authorities and delegating trust. Going back to your idea of bitcointalk/bitcoin-otc/etc. verification you'd have those services use OpenPGP to sign a special user-id on peoples' PGP keys linking their usernames to their identity in a nice standard manner. That's really useful: I'm probably going to be familiar with someone from multiple services, so having those multiple authorities tell me they are who they say they are gives me a lot of faith.

From the UI angle, the obvious way to do all this is to give people a "keep-it-simple" version where you have a pre-built set of trust anchors that comes with all this by default. In many cases this will be enough security, just like in many cases cutting-and-pasting Bitcoin addresses from emails is fine. FWIW I pushed quite hard at the dark wallet conf to give people these kinds of "good enough" options, and the underlying OpenPGP technology is absolutely capable of implementing them, as well as importing X.509-style certificates when appropriate.

But when you do need better security for a big transaction we've given users the tools they need to take things seriously and spend the time to make sure it's done right. I fully expect that a very large number of users won't choose to use those tools at all: they'll outsource the entire thing to third-party Bitcoin banks staffed with professionals who specialize in this kind of security, and they'll place their faith in the legal system and insurance instead. That's ok, it's their money. Meanwhile those who choose to do it themselves can take the time to do it right.

Finally, by using standards like OpenPGP you synergistically improve security for more than just Bitcoins: having the option to use my OpenPGP identity with my email, my code, and my transactions improves the security of all three.

Incidentally, this shows so clearly how foolish your way of viewing the world is: No reasonable human being is going to say that my bitcointalk username is my identity, I'm a person, not some bits in some database. Equally no reasonable person is going to say my Google email account is my identity. We've let the security of the SSL certificate authority system degrade to the point where a computer getting compromised, or some records in a domain registrar getting compromised, is enough for a full SSL cert compromise, and that's a very bad thing.

Accounts get hacked, and you're pushing a system where an account getting hacked is a disaster.

Lots of people do want to be known only by their forum handle. If you want a more robust verification of your real world identity, go ahead and buy a cert that shows that. I've done it, it was quite easy and the keys are stored in a smartcard. The cert has my real name on it and when it's plugged in to the USB port my mail is signed automatically with it (so I'm a weirdo who uses s/mime :-)

Now I guess I don't understand what you're arguing in the other cases. You want pgp to be used but with a pre-defined set of trust anchors (CAs) except not the regular ones because that's too centralised? Other than some   protocol differences how would that be different to what I've just proposed and we are already doing? If you want to get trust statements but not from the merchant themselves just look up signatures by cert hash in some server.

And those people can create specific OpenPGP identities for their forum handle, something people already do on bitcoin-otc, Silk Road-style marketplaces etc. For those who just want decent security on the other hand, they probably want to integrate multiple identities together - I go my "Peter Todd" here, petertodd on reddit, and petertoddbtc on twitter. I'd like to see all three cross-verifying my identity.

...and of course, often people want to be known only by a forum handle, one that they reuse on multiple sites! Again, OpenPGP can do that well, your proposed model doesn't.

re: smartcard, yeah, I got one of those too for my PGP key. Supports X.509 certs too.


Simple, I want the best of both worlds. Trust anchors CA style are fine when you recognize the limitations, so shoe-horn them into the system. WoT however is how the world really works, so make that available for when you need better security. OpenPGP can do both, what you are proposing can't.

Sure man - whatever you say, your highness!
I will go to Google and buy an SSL certificate that will ensure me being me, since it seems like to be a very honorable thing to do...

May I do it tomorrow, though?
Because today I still have some actually important things to do, others than getting my shit enlisted in yet another NSA suckers database.

This is Development & Technical discussion. If you don't want to contribute either one of those things to the discussion, go somewhere else.

If you were as smart as you pretend to be, you would have known that I am actually contributing to the Development & Technical discussion by pointing out the incompetence and conflict of interests of people who abuse a "technical discussion" to advertise themselves here as the ones who are taking care of the "development".

Let me tell you something: I've been watching you for the past few years already and you might keep fooling others, but you won't fool me.
The sad truth about the bitcoin development is: you are not taking care of any development - all you do is a "technical discussion" that leads to completely no useful development.
Either you know it and pretend to be stupid - or you are just stupid and haven't even noticed it.

So going back to a development.
The way I develop things myself is: first get rid of all the people who pretend that they try to help, though never do, just disturb because that is what they get paid for. Your friend Mike is definitively number one here, but you are also close to get on the list, so keep trying... you're almost there! :)

Anyway, in case if you didn't catch it yet, let me state it once again:
I have been watching you for years already and as much as I agree that you are good in "Technical Discussion", in reality the only thing that you have developed so far seems to be just your own shit - literally. And you might be very proud of this creation of yours, but probably only because you are unaware of the fact that your shit does not really smell nice to other people.

I agree with the base principle of both standpoints.... Mike's advocating something totally seamless that you can completely ignore if you wish, much like what happens with the present day identity information for websites.

Peter says it's not robust enough for situations where you need more assurance and/or you're working on a one-to-one basis. I can agree with that.

Mike's saying the OpenPGP solution is too much for the average user to tackle, I agree.

Peter's saying to compromise that and create an OpenPGP system that defaults to using X.509, which will in practice implement Mikes proposal, but leaves the user a nice bit of GUI to alter to use the WoT system.


Nicely implemented, what's not to like? As long as there's not loads of peculiar acronyms in menus bristling around in front of the first time Qt wallet user, then it's likely a valuable feature. As less tecchy people become more confident in bitcoin, they will feel like using it for more crucial/expensive purposes. At that stage, the idea of wrapping their mind around a concept that enables their safer use of bitcoin will be appealing, not a chore. We've moved from a world of horse and cart and telegrams into the current state of modernity through quite a few technological stop-gaps, and yet people are still willing to learn the latest thing if it improves their life. PGP will (belatedly...) come into it's own in an era like this one....

...because the 1990's e-mail + internet security model is becoming more of a real world commercial issue anyway. People will begin to come into contact with PGP just through being exposed to it at work, even if it is just that management are putting PGP signatures on their mails. What's that you're saying, that your boss wouldn't start doing that? Perhaps that may begin to be the difference between businesses that thrive and those that disappear.

That's an excellent summary.

How to actually implement it is an interesting question: My understanding is that BouncyCastle for Java implements low-level OpenPGP primitives well, and for Javacsript I hear good things about openpgpjs. Mainly though, when you're talking about doing new certificate authorities, rather than existing systems, my point is that the OpenPGP infrastructure is already there to a much greater degree than people realize. Even something as simple as having the ability to have multiple signatures on a payment request is a good start.

Incidentally, if we find that existing OpenPGP implementations aren't up to the task, I think it's good to use this as an opportunity to change that; we're not the only community with a renewed interest in it.
 

Agreed. I really worry that we're going to find the hard way that stealing valuable, untracable, fungible, digital money is so much more universally attractive than other types of digital malice that previous assumptions about what kind of security is "good enough" are going to be proven very wrong. We're much better off if our not-totally-secure but easy to use software has functionality under the hood to improve on the situation quickly if needed.

To summarize:

- Clearly it looks like the idea by Agent Hearn got no support from the community.
- Let's wait like 3 till 5 more days, if no supporters of this idea pop up, let's forget it.

No need for harsh words. :)

tl;dr

Why not PGP for this?

Because Google claims that "the PGP model has been around for decades and is a practical failure"

A bold statement less than 48 hours after the proposal.

Why not wait a few releases of wallet software?
That's what the proposal is all about, giving developers an idea for a feature they might want to add.

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.

"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.

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 ;)

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.

"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.

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.

"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.

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.


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.

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?


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


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.

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 :)

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."?

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 (https://github.com/moxie0/Convergence), that is nothing to do with DNS.

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."

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

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.

https://i.imgur.com/ectkUyk.jpg