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.
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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