1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 00C659F2
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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.
|
