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
|
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 6BBD5ACC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2015 11:45:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com
[209.85.223.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 70DAD1A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2015 11:45:07 +0000 (UTC)
Received: by iebmu5 with SMTP id mu5so9158124ieb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jul 2015 04:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=j1XT6yjTybdvHkboM4ulAMxtZy4XstWbSwUz5v+vFDk=;
b=MH9QWPTXGU081vVE06lwI2jt/0GWlWOiavhxhCw32K4EWxXRbvPxPts3VEd8tRlZQ6
M5wOQBxVVcVVqccbiILN6MdToLK/fwcrah1AEkdt3/trbkELjf71F4gLqbf+6euczSM3
h2smhIAvFDwcGZOj81Nsnlh2fjNSsp50S3QLk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=j1XT6yjTybdvHkboM4ulAMxtZy4XstWbSwUz5v+vFDk=;
b=bM2yNjz6owKPd/gSaAlgFCHkJrPQMMpt15ZvoGK8zWBYehTqzSHa7P9nK8CESGUqBB
SrYCtnHPqAqKI/lIuBBGGbJoVmP9TTSJe3FfDIgheXyzXDK/WhU4ojyCTLkz153vlqRL
YzN9qdMunmrdw0TBJwVgsZNK0xd2rG4MwMreHtHhUD6DzqQpZBKZiTcfkdC22nXGrvuD
0d5br57J8fXUbX1yv/LwQLj9cGq6AQZ2Xs6L+jHhEsaS1PWaunzxS7/6YzJtls6WMm/Q
DaT2XczzfWLUE7WE7M8FBUHH6eL3xuqOvY4yex+DCspfQAtI6Xh9p72DZ6jE9F2kvDgJ
fixA==
X-Gm-Message-State: ALoCoQk2meG/UXDKXw4QlGnr984XUt2rQGiNZrTG9TZU1oCyIAQq+PeSi18+kcDuP8xD6say9teV
MIME-Version: 1.0
X-Received: by 10.107.6.194 with SMTP id f63mr48689359ioi.61.1436874306894;
Tue, 14 Jul 2015 04:45:06 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Tue, 14 Jul 2015 04:45:06 -0700 (PDT)
In-Reply-To: <55A4AF62.4090607@electrum.org>
References: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>
<55A4AF62.4090607@electrum.org>
Date: Tue, 14 Jul 2015 13:45:06 +0200
Message-ID: <CA+w+GKRCPEUezaTb46pzuDNxKNgi_KdTW2dOn9hsHwgD159czw@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Thomas Voegtlin <thomasv@electrum.org>
Content-Type: multipart/alternative; boundary=001a113fc442a65760051ad45e2b
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
Cc: bitcoin-dev@lists.linuxfoundation.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 11:45:08 -0000
--001a113fc442a65760051ad45e2b
Content-Type: text/plain; charset=UTF-8
Hi Thomas,
Re: NetKi, I think any proposal in this space has to be an open standard,
almost by the definition of what it is. At any rate, it may be worth
talking to them. They have signed up to implement their system at least.
I did understand that your proposal does not rely on email - for instance a
web forum could issue username@reddit.com type aliases, even if those are
not also email accounts. I am just continuing the comparison against email
address certs.
It's also the case that a domain can use the DKIM setup without actually
offering email accounts. They can just have a web form or API that triggers
sending of the signed email (or simply, providing the signed headers
themselves). Thus the same system can be used transparently by both email
providers and other sites that don't give their users email addresses, but
would still like to use the same system.
Hardly anyone uses email certificates today, so I don't think it would
> affect a lot of users.
No, but obviously we'd like to change that! The holdup is not the
certificate side of things, really, but rather the lack of a
store-and-forward network for signed payment requests. I keep asking
someone to build one but I fear the problem is almost too simple ......
everyone who looks at this decides to solve 12 other problems
simultaneously, it gets complicated, then they never launch :(
Once there's a simple and robust way to get PaymentRequest's from one end
user to another, even when that first user is offline, then getting an
email cert issued is no big deal.
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.
>
Any solution that separates identity providers from certificate issuers
would have these requirements, though. And as many identity providers today
do not wish to become CAs too, it seems fundamental.
I don't think it's such a problem, mind you. The crt.sh website is actually
a frontend to the CT protocol, which is a somewhat blockchain like audit
log that's eventually intended to contain all issued certificates. Right
now, of course, they focus on SSL certs because those are the most common
and important. If other kinds of certs became more widely used, support in
the infrastructure would follow.
Don't get me wrong - I would like to see a way for a domain to delegate
BIP70 signing power to a third party. For instance, this would mean payment
processors like BitPay could sign on the behalf of the merchant, and the
merchant identity would then show up in wallets. The "chain a cert off a
domain cert" trick would be a good way to do that, though rather than
hacking the X.509 stack to validate invalid stuff, at this point it may as
well be a custom (better) cert format. There's little reason to use X.509
beyond backwards compatibility.
But the most popular identity providers today either don't care about
Bitcoin at all, or worse, are developing competitors to it. So for real
adoption to occur, we must have solutions that do not require identity
provider cooperation. I realise this is a business reason rather than a
technical reason, but it's a very strong one - so bootstrapping off
existing infrastructure with a split CA/ID provider design still makes much
more sense to me.
--001a113fc442a65760051ad45e2b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Thomas,<div><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div><br></div><div>Re: NetKi, I think any proposal in this spac=
e has to be an open standard, almost by the definition of what it is. At an=
y rate, it may be worth talking to them. They have signed up to implement t=
heir system at least.</div><div><br></div><div>I did understand that your p=
roposal does not rely on email - for instance a web forum could issue <a hr=
ef=3D"mailto:username@reddit.com">username@reddit.com</a> type aliases, eve=
n if those are not also email accounts. I am just continuing the comparison=
against email address certs.</div><div><br></div><div>It's also the ca=
se that a domain can use the DKIM setup without actually offering email acc=
ounts. They can just have a web form or API that triggers sending of the si=
gned email (or simply, providing the signed headers themselves). Thus the s=
ame system can be used transparently by both email providers and other site=
s that don't give their users email addresses, but would still like to =
use the same system.</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Har=
dly anyone uses email certificates today, so I don't think it would<br>
affect a lot of users.</blockquote><div><br></div><div>No, but obviously we=
'd like to change that! The holdup is not the certificate side of thing=
s, really, but rather the lack of a store-and-forward network for signed pa=
yment requests. I keep asking someone to build one but I fear the problem i=
s almost too simple ...... everyone who looks at this decides to solve 12 o=
ther problems simultaneously, it gets complicated, then they never launch :=
(</div><div><br></div><div>Once there's a simple and robust way to get =
PaymentRequest's from one end user to another, even when that first use=
r is offline, then getting an email cert issued is no big deal.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">That does not look so... not until =
(1) BIP70 wallets integrate with<br>
<a href=3D"https://crt.sh" rel=3D"noreferrer" target=3D"_blank">https://crt=
.sh</a>, (2) you convince that service to index email certs (3)<br>
you convince all CAs to report all email certs they issue to crt.sh.<br></b=
lockquote><div><br></div><div>Any solution that separates identity provider=
s from certificate issuers would have these requirements, though. And as ma=
ny identity providers today do not wish to become CAs too, it seems fundame=
ntal.</div><div><br></div><div>I don't think it's such a problem, m=
ind you. The crt.sh website is actually a frontend to the CT protocol, whic=
h is a somewhat blockchain like audit log that's eventually intended to=
contain all issued certificates. Right now, of course, they focus on SSL c=
erts because those are the most common and important. If other kinds of cer=
ts became more widely used, support in the infrastructure would follow.</di=
v><div><br></div><div><br></div><div><br></div><div>Don't get me wrong =
- I would like to see a way for a domain to delegate BIP70 signing power to=
a third party. For instance, this would mean payment processors like BitPa=
y could sign on the behalf of the merchant, and the merchant identity would=
then show up in wallets. The "chain a cert off a domain cert" tr=
ick would be a good way to do that, though rather than hacking the X.509 st=
ack to validate invalid stuff, at this point it may as well be a custom (be=
tter) cert format. There's little reason to use X.509 beyond backwards =
compatibility.</div><div><br></div><div>But the most popular identity provi=
ders today either don't care about Bitcoin at all, or worse, are develo=
ping competitors to it. So for real adoption to occur, we must have solutio=
ns that do not require identity provider cooperation. I realise this is a b=
usiness reason rather than a technical reason, but it's a very strong o=
ne - so bootstrapping off existing infrastructure with a split CA/ID provid=
er design still makes much more sense to me.</div></div></div></div></div>
--001a113fc442a65760051ad45e2b--
|
