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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F18FB13
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jul 2015 22:31:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com
[209.85.223.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D2EB176
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jul 2015 22:31:37 +0000 (UTC)
Received: by ieik3 with SMTP id k3so32475584iei.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jul 2015 15:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=wu89aIxYuH22d45z9x9DNQktgX0TXoBvX5Mhe2NMGic=;
b=lWmldmlOIGkZ+8tDkut/O0y/+UD/G5Y6fmFIkz8Q1P9XVJsNCS21pwZMg/0GGcu9ao
traUpQHVoRgwG0FkxWoitaldkpEvX5ngmnWBFCjQdhRaun0vI5xj2DRBMuNFmRguToAW
I8ptzorRC6UQr1kwsaN/D5e/9z6V1bTnbxe2Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
:content-type;
bh=wu89aIxYuH22d45z9x9DNQktgX0TXoBvX5Mhe2NMGic=;
b=kEjs6GESfall/cuwajsMYg98toYpAppFkLXymwTciWEPuC8QUthmQQHKigIC//uV9J
Znl8e6MVPSjc2r/W/iXPaeHkbmLWcCF6dnjJFTMj0hTQmqNsfcdpC03/mYgTK63rhpXR
clcHvH+OmCadT22jQAy/3LdWCa3VAqwn/07fFjdfyClwPKoxeX0iN1oVmpNDGK1ihDOM
5oxNoc8N6WQlUsvPni1k1fG6jugS+bCbePyEzgijpQVYuNna1TGkHNGYXJihqGYKOO4p
8thJcMIG3MRZZVmfhq5pOeC3GyQSof9gSQGG5pbUUd7hqrgYfDTPAuQ/wYScLoVHgBnt
5aGw==
X-Gm-Message-State: ALoCoQnLwKjEohVwYOkO32ik6CN5qpmRB283Qm7OpywhUr790Wqs8pqNbihzWetYAs3A7va/78CD
MIME-Version: 1.0
X-Received: by 10.107.19.21 with SMTP id b21mr731032ioj.78.1436826696811; Mon,
13 Jul 2015 15:31:36 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Mon, 13 Jul 2015 15:31:36 -0700 (PDT)
Date: Tue, 14 Jul 2015 00:31:36 +0200
Message-ID: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: bitcoin-dev@lists.linuxfoundation.org, thomasv@electrum.org
Content-Type: multipart/alternative; boundary=001a113f648ede2700051ac948de
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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: Mon, 13 Jul 2015 22:31:38 -0000
--001a113f648ede2700051ac948de
Content-Type: text/plain; charset=UTF-8
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
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.
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.
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.
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? 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.
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:
1. User sends a public key in the subject line to a one-time collector
address like <random-number>@publish-email-headers.net (who runs this
service is arbitrary as they do not need to be trusted). On receiving the
email, the headers are made available via
https://publish-email-headers.net/<random-number> for download by the
users wallet.
2. The act of sending the email triggers DKIM signing of the subject
line and From header, and thus, the public key and email address are bound
together via the ESP's own signing key.
3. The textual email headers can be run through the DKIM validation
algorithm in combination with the domain key retrieved via DNS.
With this scheme, setup is largely automatic and involves the wallet asking
the operating system to open a mailto: URL. The user just has to press
"send" and the wallet can then sit on a long-lived HTTPS connection waiting
for the headers to turn up. Once the headers are downloaded, they can be
saved to disk and this becomes your "DKIM certificate" which can then be
used with a new pki_type in BIP70.
Note the following useful characteristics of this approach:
1. It does not require the email provider to know/care about Bitcoin.
DKIM is already widely deployed by major email providers due to its
benefits for spam and phishing protection: the majority of all email on the
internet is DKIM signed. So you automatically have a system that works with
nearly all consumer email accounts.
2. The enrolment UI is straightforward, assuming the user has a working
mailto: handler on their system. Even webmail services like Gmail can
attach themselves to mailto: handling these days.
3. There are DKIM validation libraries already in existence, so new code
required is minimal.
And the downsides:
1. There is no way to revoke such a "certificate" because you have, of
course, abandoned the PKI which specifies how to handle all these details.
You could potentially hijack/reuse OCSP to allow such a custom cert to be
revoked, but then the question is, who actually runs such a revocation
server. Doing things like this is why we have CAs in the first place.
2. The UX leaves a bit of binary nonsense in the users sent folder that
clutters up their account.
3. Does it even solve the right problem? A lot of users don't actually
use emails as identifiers anymore. In the modern world people are using
their social networking profiles (i.e. Facebook) and phone numbers (e.g.
for WhatsApp) as the personal identifier of choice. Email address support
might be solving yesterdays problem.
--001a113f648ede2700051ac948de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Thomas,<div><br></div><div>FYI there is a company calle=
d Netki is also working on a kind of DNSSEC integration with BIP70, there&#=
39;s a thread here about their efforts:</div><div><br></div><div>=C2=A0 =C2=
=A0 =C2=A0<a href=3D"https://groups.google.com/forum/#!searchin/bitcoinj/dn=
ssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J">https://groups.google.com/forum/#!s=
earchin/bitcoinj/dnssec/bitcoinj/QFAH1F2dEwE/36oWDwREEV4J</a><br></div><div=
><br></div><div>If you would like to work on this, perhaps it's worth t=
eaming up with them? Obviously they plan to have an open spec and open sour=
ce implementation.</div><div><br></div><div>Now w.r.t. the other things - I=
think we have discussed this before, but to reiterate: =C2=A0the biggest f=
law with doing things the way you suggest is that in practice, no email pro=
vider is going to implement your scheme any time soon. Most obviously the b=
ig web mail providers won't. Therefore hardly anyone will use it.=C2=A0=
</div><div><br></div><div>Whilst having an extension cannot really hurt, ob=
viously, BIP70 will not be amended to reduce the certificate types it allow=
s 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.</div><div><b=
r></div><div>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 unab=
le to revoke it? But that's not quite true. Every CA I know of allows y=
ou to revoke a certificate that was issued for your email address if you ha=
ve access to that email address. Now, if you don't know that this issua=
nce took place, you cannot invoke that procedure of course .... but that=
9;s what certificate transparency is already working on solving in a scalab=
le manner:</div><div><br></div><div>=C2=A0 <a href=3D"https://crt.sh/">http=
s://crt.sh/</a><br></div><div><br></div><div>That site doesn't currentl=
y index email address certs, but it certainly could with minimal extra effo=
rt by the creators as they're almost identical to domain name certs.</d=
iv><div><br></div><div>So the existing infrastructure seems to have everyth=
ing in place to solve that issue.</div><div><br></div><div>Now, if you stil=
l want a mechanism that eliminates the CA entirely, I think there's a b=
etter approach which is backwards compatible with existing email providers.=
It works like this:</div><div><ol><li>User sends a public key in the subje=
ct line to a one-time collector address like <random-number>@<a href=
=3D"http://publish-email-headers.net">publish-email-headers.net</a> =C2=A0 =
=C2=A0(who runs this service is arbitrary as they do not need to be trusted=
). On receiving the email, the headers are made available via <a href=3D"ht=
tps://publish-email-headers.net/">https://publish-email-headers.net/</a><=
;random-number> for download by the users wallet.<br><br></li><li>The ac=
t of sending the email triggers DKIM signing of the subject line and From h=
eader, and thus, the public key and email address are bound together via th=
e ESP's own signing key.<br><br></li><li>The textual email headers can =
be run through the DKIM validation algorithm in combination with the domain=
key retrieved via DNS.</li></ol><div>With this scheme, setup is largely au=
tomatic and involves the wallet asking the operating system to open a mailt=
o: URL. The user just has to press "send" and the wallet can then=
sit on a long-lived HTTPS connection waiting for the headers to turn up. O=
nce the headers are downloaded, they can be saved to disk and this becomes =
your "DKIM certificate" which can then be used with a new pki_typ=
e in BIP70.</div></div><div><br></div><div>Note the following useful charac=
teristics of this approach:</div><div><ol><li>It does not require the email=
provider to know/care about Bitcoin. DKIM is already widely deployed by ma=
jor email providers due to its benefits for spam and phishing protection: t=
he majority of all email on the internet is DKIM signed. So you automatical=
ly have a system that works with nearly all consumer email accounts.<br><br=
></li><li>The enrolment UI is straightforward, assuming the user has a work=
ing mailto: handler on their system. Even webmail services like Gmail can a=
ttach themselves to mailto: handling these days.<br><br></li><li>There are =
DKIM validation libraries already in existence, so new code required is min=
imal.<br></li></ol><div>And the downsides:</div></div><div><ol><li>There is=
no way to revoke such a "certificate" because you have, of cours=
e, abandoned the PKI which specifies how to handle all these details. You c=
ould potentially hijack/reuse OCSP to allow such a custom cert to be revoke=
d, but then the question is, who actually runs such a revocation server. Do=
ing things like this is why we have CAs in the first place.<br><br></li><li=
>The UX leaves a bit of binary nonsense in the users sent folder that clutt=
ers up their account.<br><br></li><li>Does it even solve the right problem?=
A lot of users don't actually use emails as identifiers anymore. In th=
e modern world people are using their social networking profiles (i.e. Face=
book) and phone numbers (e.g. for WhatsApp) as the personal identifier of c=
hoice. Email address support might be solving yesterdays problem.</li></ol>=
<div><br></div></div></div>
--001a113f648ede2700051ac948de--
|
