From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 00C659F2 for ; Tue, 14 Jul 2015 06:42:46 +0000 (UTC) X-Greylist: delayed 17:36:33 by SQLgrey-1.7.6 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C4515B0 for ; Tue, 14 Jul 2015 06:42:45 +0000 (UTC) Received: from mfilter43-d.gandi.net (mfilter43-d.gandi.net [217.70.178.174]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 37C5FFB882 for ; Tue, 14 Jul 2015 08:42:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter43-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter43-d.gandi.net (mfilter43-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id bzXT7X9Y-edN for ; Tue, 14 Jul 2015 08:42:42 +0200 (CEST) X-Originating-IP: 92.229.101.74 Received: from [192.168.1.2] (x5ce5654a.dyn.telefonica.de [92.229.101.74]) (Authenticated sender: thomasv@electrum.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id AE41BFB887 for ; Tue, 14 Jul 2015 08:42:42 +0200 (CEST) Message-ID: <55A4AF62.4090607@electrum.org> Date: Tue, 14 Jul 2015 08:42:42 +0200 From: Thomas Voegtlin 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: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 06:42:47 -0000 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.