public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Thomas Voegtlin <thomasv@electrum.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Date: Tue, 14 Jul 2015 08:42:42 +0200	[thread overview]
Message-ID: <55A4AF62.4090607@electrum.org> (raw)
In-Reply-To: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>

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.


  reply	other threads:[~2015-07-14  6:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-13 22:31 [bitcoin-dev] Proposal: extend bip70 with OpenAlias Mike Hearn
2015-07-14  6:42 ` Thomas Voegtlin [this message]
2015-07-14 11:19   ` Milly Bitcoin
2015-07-14 13:13     ` Thomas Voegtlin
2015-07-14 11:45   ` Mike Hearn
2015-07-19 11:18     ` Thomas Voegtlin
2015-07-20 13:46       ` Mike Hearn
2015-07-20 14:32         ` Thomas Voegtlin
2015-07-20 14:42           ` Mike Hearn
2015-07-20 14:52             ` Thomas Voegtlin
2015-07-20 15:14               ` Mike Hearn
2015-07-20 15:34                 ` Thomas Voegtlin
2015-07-20 16:09                   ` Mike Hearn
  -- strict thread matches above, loose matches on Subject: below --
2015-07-27 22:46 Riccardo Spagni
2015-07-18 11:40 Riccardo Spagni
2015-07-18 11:46 ` Mike Hearn
2015-07-17  8:00 Riccardo Spagni
2015-07-18 11:21 ` Mike Hearn
2015-07-16 16:18 Riccardo Spagni
2015-07-14 19:07 Riccardo Spagni
2015-07-17  0:55 ` Justin Newton
2015-07-17  0:58   ` Justin Newton
2015-07-17  1:01   ` Justin Newton
2015-07-17  1:02     ` Justin Newton
2015-07-23  9:48     ` Thomas Voegtlin
2015-07-23 13:07       ` Thomas Voegtlin
2015-07-27 21:51         ` Justin Newton
2015-07-31 20:34           ` Thomas Voegtlin
2015-07-14 17:29 Justin Newton
2015-07-18 13:29 ` Thomas Voegtlin
2015-07-18 23:01   ` Justin Newton
2015-07-20  8:56     ` Thomas Voegtlin
2015-07-14  8:29 Riccardo Spagni
     [not found] <55A3B52C.9020003@electrum.org>
2015-07-13 13:06 ` Thomas Voegtlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A4AF62.4090607@electrum.org \
    --to=thomasv@electrum.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox