Message-ID: <55A4AF62.4090607@electrum.org>
Date: Tue, 14 Jul 2015 08:42:42 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>
In-Reply-To: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Precedence: list

Mike Hearn wrote:

> Hi Thomas,
>=20
> FYI there is a company called Netki is also working on a kind of DNSSEC
> integration with BIP70,=20
> there's a thread here about their efforts:
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFA=
H1F2dEwE/36oWDwREEV4J

Hi Mike,

Thanks! I believe it is better to keep the current discussion on
bitcoin-dev, though.

> If you would like to work on this, perhaps it's worth teaming up with t=
hem?
> Obviously they plan to have an open spec and open source implementation=
.
>=20

I would love to work with Netki. However, it's not clear to me what they
are selling. OpenAlias is an open standard, not a company. In contrast,
Netki have very long Terms of Service, that do not help understand what
part of their solution is open-source, and what is the product. They
surely know about OpenAlias, it would be nice to hear what they think
about it.

> Now w.r.t. the other things - I think we have discussed this before, bu=
t to
> reiterate:  the biggest flaw with doing things the way you suggest is t=
hat
> in practice, no email provider is going to implement your scheme any ti=
me
> soon. Most obviously the big web mail providers won't. Therefore hardly
> anyone will use it.
>=20

What I propose does not rely on email. Please read again.
I am proposing an alternative way to sign BIP70 requests. This is
independent from the communication channel used to send/receive them.

> Whilst having an extension cannot really hurt, obviously, BIP70 will no=
t be
> amended to reduce the certificate types it allows in favour of a system
> that has a very low chance of mainstream adoption. Restricting options =
like
> that would just make no sense at all.
>=20

Hardly anyone uses email certificates today, so I don't think it would
affect a lot of users. In contrast, it would increase the security of
all users who don't use email certs, because they may receive a payment
request signed by an email cert.

> I think your primary concern is that if your email account is hacked,
> someone could get a cert issued in your name, and you'd be unable to re=
voke
> it?=20

If your email account is hacked and someone else gets a certificate in
your name, you'd be unable to *know* about it, because they would use a
different CA.

> But that's not quite true. Every CA I know of allows you to revoke a
> certificate that was issued for your email address if you have access t=
o
> that email address. Now, if you don't know that this issuance took plac=
e,
> you cannot invoke that procedure of course .... but that's what certifi=
cate
> transparency is already working on solving in a scalable manner:
>=20
>   https://crt.sh/
>=20
> That site doesn't currently index email address certs, but it certainly
> could with minimal extra effort by the creators as they're almost ident=
ical
> to domain name certs.
>=20
> So the existing infrastructure seems to have everything in place to sol=
ve
> that issue.=20

That does not look so... not until (1) BIP70 wallets integrate with
https://crt.sh, (2) you convince that service to index email certs (3)
you convince all CAs to report all email certs they issue to crt.sh.

Good luck with that!


> Now, if you still want a mechanism that eliminates the CA entirely, I t=
hink
> there's a better approach which is backwards compatible with existing e=
mail
> providers. It works like this: [...]

Again, that olution is for email only. We both agree that this is
solving yesterdays problems, so there's no need to discuss that.