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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@coinqy.com>) id 1XBgnz-0006ey-Af
for bitcoin-development@lists.sourceforge.net;
Mon, 28 Jul 2014 09:01:15 +0000
Received: from prei.vps.van-cuijk.nl ([79.170.90.37])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1XBgnx-0000c7-7G
for bitcoin-development@lists.sourceforge.net;
Mon, 28 Jul 2014 09:01:15 +0000
Received: from [192.168.29.45] (unknown [89.146.26.107])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested) (Authenticated sender: mo_mark)
by prei.vps.van-cuijk.nl (Postfix) with ESMTPSA id 5803341C32;
Mon, 28 Jul 2014 11:01:06 +0200 (CEST)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_D08E4638-E5B2-48DF-8A12-E0560CC86CC8"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Mark van Cuijk <mark@coinqy.com>
In-Reply-To: <CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
Date: Mon, 28 Jul 2014 11:01:06 +0200
Message-Id: <C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
References: <B097D5C5-8E9E-461D-8FF3-58A661AFB3CB@coinqy.com>
<CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
X-Mailer: Apple Mail (2.1874)
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1XBgnx-0000c7-7G
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 28 Jul 2014 09:01:15 -0000
--Apple-Mail=_D08E4638-E5B2-48DF-8A12-E0560CC86CC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Good to see that it has been discussed, but I see the idea has been =
postponed. I agree our proposals don=92t differ substantially. Besides =
naming, I think the differences are the algorithms that are used for =
signing the extended certificate / mandate by the merchant and the way =
backwards compatibility is handled.
Also taking into consideration the replies on your proposal, I think the =
following decisions are most important to be made when we make a step =
back:
What party/system do we want to rely on to verify the identity of the =
merchant? Options I=92ve seen:
- X.509 CAs
- Payment Processors (PP)
- PGP/Bitcoin-based
Which =93PKI" do we want to use to identify the merchant (related to the =
previous question)?
- X.509 certificate
- Merchant identifier
- Twitter handle
Which =93PKI=94 do we want to use to authenticate the PP?
- X.509 certificate
- Extended certificate
My personal opinion:
I=92d prefer to stick to the X.509 system for identification of the =
merchant, even though the system is not perfect. In the case of a =
webshop transaction, a customer probably already relies on the X.509 =
system to authenticate the identity of the merchant during the shopping =
session (HTTPS) in his browser when he transmits his personal data like =
his address. I=92d prefer not to add a competing identification system a =
customer also needs to rely on, unless that system brings objective =
improvements and can also be used in the HTTPS session.
I do like the idea coined by Mike that a PP can issue non-SSL =
certificates for the purpose of merchant identification, as long as a =
customer is free to determine whether he trusts the PP for this purpose.
Regarding the choice of how to authenticate the PP, I=92m a bit =
undetermined. Disregarding backward compatibility, I think the extended =
certificate system proposed by Mike is cleaner. However, I don=92t like =
the concept of requiring two separate signatures for old and new =
clients. Taking backward compatibility in mind, I tend to prefer my =
proposal.
/Mark
On 27 Jul 2014, at 21:31 , Mike Hearn <mike@plan99.net> wrote:
> Hi Mark,
>=20
> This is very similar to a proposal I made some time ago:
>=20
> =
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/m=
sg04053.html
>=20
> I think the outlines of a design are clear - my proposal and yours =
don't I think differ substantially. Someone needs to make it happen =
though.
>=20
>=20
--Apple-Mail=_D08E4638-E5B2-48DF-8A12-E0560CC86CC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Good to see that it has been discussed, but I =
see the idea has been postponed. I agree our proposals don=92t differ =
substantially. Besides naming, I think the differences are the =
algorithms that are used for signing the extended certificate / mandate =
by the merchant and the way backwards compatibility is =
handled.</div><div><br></div><div>Also taking into consideration the =
replies on your proposal, I think the following decisions are most =
important to be made when we make a step =
back:</div><div><br></div><div>What party/system do we want to rely on =
to verify the identity of the merchant? Options I=92ve seen:</div><div>- =
X.509 CAs</div><div>- Payment Processors (PP)</div><div>- =
PGP/Bitcoin-based</div><div><br></div><div>Which =93PKI" do we want to =
use to identify the merchant (related to the previous =
question)?</div><div>- X.509 certificate</div><div>- Merchant =
identifier</div><div>- Twitter handle</div><div><br></div><div>Which =
=93PKI=94 do we want to use to authenticate the PP?</div><div>- X.509 =
certificate</div><div>- Extended certificate</div><div><br></div><div>My =
personal opinion:</div><div><br></div><div>I=92d prefer to stick to the =
X.509 system for identification of the merchant, even though the system =
is not perfect. In the case of a webshop transaction, a customer =
probably already relies on the X.509 system to authenticate the identity =
of the merchant during the shopping session (HTTPS) in his browser when =
he transmits his personal data like his address. I=92d prefer not to add =
a competing identification system a customer also needs to rely on, =
unless that system brings objective improvements and can also be used in =
the HTTPS session.</div><div><br></div><div>I do like the idea coined by =
Mike that a PP can issue non-SSL certificates for the purpose of =
merchant identification, as long as a customer is free to determine =
whether he trusts the PP for this =
purpose.</div><div><br></div><div>Regarding the choice of how to =
authenticate the PP, I=92m a bit undetermined. Disregarding backward =
compatibility, I think the extended certificate system proposed by Mike =
is cleaner. However, I don=92t like the concept of requiring two =
separate signatures for old and new clients. Taking backward =
compatibility in mind, I tend to prefer my =
proposal.</div><div><br></div><div>/Mark</div><div><br><div><div>On 27 =
Jul 2014, at 21:31 , Mike Hearn <<a =
href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr">Hi Mark,<div><br></div><div>This is very similar to a =
proposal I made some time ago:</div><div><br></div><div> <a =
href=3D"https://www.mail-archive.com/bitcoin-development%40lists.sourcefor=
ge.net/msg04053.html">https://www.mail-archive.com/bitcoin-development%40l=
ists.sourceforge.net/msg04053.html</a><br>
</div><div><br></div><div>I think the outlines of a design are clear - =
my proposal and yours don't I think differ substantially. Someone needs =
to make it happen though.</div><div =
class=3D"gmail_extra"><br><br></div></div>
</blockquote></div><br></div></body></html>=
--Apple-Mail=_D08E4638-E5B2-48DF-8A12-E0560CC86CC8--
|
