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
|
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 1XBkdV-0006xR-1t
for bitcoin-development@lists.sourceforge.net;
Mon, 28 Jul 2014 13:06:41 +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 1XBkdT-0008HZ-Iu
for bitcoin-development@lists.sourceforge.net;
Mon, 28 Jul 2014 13:06:41 +0000
Received: from [192.168.144.136] (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 1771E41C32;
Mon, 28 Jul 2014 15:06:27 +0200 (CEST)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_03BEA670-DFAC-4369-B429-9C9AEE5C768E"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Mark van Cuijk <mark@coinqy.com>
In-Reply-To: <CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
Date: Mon, 28 Jul 2014 15:06:26 +0200
Message-Id: <5E988ED7-845D-4982-9240-155AACD20F66@coinqy.com>
References: <B097D5C5-8E9E-461D-8FF3-58A661AFB3CB@coinqy.com>
<CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
<C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
<CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
X-Mailer: Apple Mail (2.1878.6)
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: 1XBkdT-0008HZ-Iu
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 13:06:41 -0000
--Apple-Mail=_03BEA670-DFAC-4369-B429-9C9AEE5C768E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On 28 Jul 2014, at 14:46 , Mike Hearn <mike@plan99.net> wrote:
> 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.
>=20
> I don't think I proposed this exactly? It's the other way around - a =
merchant issues an extension cert to allow the PP to act on their =
behalf.
I referred to your idea in =
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/m=
sg04076.html which is indeed not the proposal itself.
> 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.
>=20
> I'm not sure I understand. Your proposal also has two signatures. =
Indeed it must because delegation of authority requires a signature, but =
old clients won't understand it.
I=92ll rephrase what I intended to say. In your proposal two signatures =
need to be computed over the payment request data, one with the key =
related to the X.509 certificate (for backwards compatibility) and one =
with the ECDSA public key. On my proposal only one signature needs to be =
computed over the payment request data using the former key, the same =
way it happens now.
Indeed there is another signature, which is to authenticate the payment =
delegation. If you take it into account in the signature count, then =
your proposal has three signatures.
/Mark=
--Apple-Mail=_03BEA670-DFAC-4369-B429-9C9AEE5C768E
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;">On 28 =
Jul 2014, at 14:46 , Mike Hearn <<a =
href=3D"mailto:mike@plan99.net">mike@plan99.net</a>> =
wrote:<br><div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto;"><div style=3D"word-wrap:break-word">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.<br>
</div></blockquote><div><br></div><div>I don't think I proposed this =
exactly? It's the other way around - a merchant issues an extension cert =
to allow the PP to act on their =
behalf.</div></div></div></div></blockquote><div><br></div>I referred to =
your idea in <a =
href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourceforge=
.net/msg04076.html">https://www.mail-archive.com/bitcoin-development%40lis=
ts.sourceforge.net/msg04076.html</a> which is indeed not the =
proposal itself.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div></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.<br>
</div></div></blockquote><div><br></div><div>I'm not sure I understand. =
Your proposal also has two signatures. Indeed it must because delegation =
of authority requires a signature, but old clients won't understand =
it.</div>
</div></div></div>
</blockquote><br></div><div>I=92ll rephrase what I intended to say. In =
your proposal two signatures need to be computed over the payment =
request data, one with the key related to the X.509 certificate (for =
backwards compatibility) and one with the ECDSA public key. On my =
proposal only one signature needs to be computed over the payment =
request data using the former key, the same way it happens =
now.</div><div><br></div><div>Indeed there is another signature, which =
is to authenticate the payment delegation. If you take it into account =
in the signature count, then your proposal has three =
signatures.</div><br><div>/Mark</div></body></html>=
--Apple-Mail=_03BEA670-DFAC-4369-B429-9C9AEE5C768E--
|
