Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

[Thomas Voegtlin <thomasv@electrum.org>]

Mike Hearn wrote:

> Hi Thomas,
> 
> FYI there is a company called Netki is also working on a kind of DNSSEC
> integration with BIP70, 
> there's a thread here about their efforts:
> https://groups.google.com/forum/#!searchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/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 them?
> Obviously they plan to have an open spec and open source implementation.
> 

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, but to
> reiterate:  the biggest flaw with doing things the way you suggest is that
> in practice, no email provider is going to implement your scheme any time
> soon. Most obviously the big web mail providers won't. Therefore hardly
> anyone will use it.
> 

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

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 revoke
> it? 

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 to
> that email address. Now, if you don't know that this issuance took place,
> you cannot invoke that procedure of course .... but that's what certificate
> transparency is already working on solving in a scalable manner:
> 
>   https://crt.sh/
> 
> That site doesn't currently index email address certs, but it certainly
> could with minimal extra effort by the creators as they're almost identical
> to domain name certs.
> 
> So the existing infrastructure seems to have everything in place to solve
> that issue. 

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 think
> there's a better approach which is backwards compatible with existing email
> 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.