Re: [Bitcoin-development] Payment protocol for onion URLs.

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Mon, Oct 28, 2013 at 1:14 PM, Adam Back <adam@cypherspace.org> wrote:

> Maybe I voice this opinion a bit late in the cycle, but ....


A bit late is one way to put it. All these topics and more were discussed
to death a year ago when the payment protocol was first being designed.
Bluntly, I think we're all sick of it. You are welcome to PGP sign your
payment requests if you want to. If not, then please see my FAQ for
discussion:

   https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143

tl;dr - the right way to tackle governments getting bogus certs issued is
certificate transparency. All other suggestions tend to boil down to
"here's some handwaving that doesn't actually solve the problem".

By the way, the evidence from the Snowden case rather reinforces the
strength of the CA system. Did we see stories about bulk usage of fake
certificates? No. What we read is that the increased usage of SSL was a
major game-changer for intelligence agencies. They "solve" SSL by compiling
databases of private keys they obtain in various ways. True to form when
the FBI wanted access to LavaBit, they tried to obtain his private keys
rather than just push a convenient "give me a fake cert" button, and when
it became known that Lavabit had to hand over their key, GoDaddy revoked
their certificate. Industry policies forced their hand and those policies
don't have a get-out clause for the FBI.

It's without a doubt that there are government-issued fake certs floating
about, somewhere, just due to the scale of hacking that's been taking
place. However, demanding perfection in a system that handles security for
over a billion people and tens of millions of operators is unreasonable.
All we can ask for is that it it's being improved, which through
initiatives like cert transparency, it is.

Please, let's call time on these discussions. They long ago ceased to have
any value.

[-- Attachment #2: Type: text/html, Size: 2557 bytes --]