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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1XBkKC-00063x-W6
for bitcoin-development@lists.sourceforge.net;
Mon, 28 Jul 2014 12:46:45 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XBkKC-0008IQ-0U
for bitcoin-development@lists.sourceforge.net;
Mon, 28 Jul 2014 12:46:44 +0000
Received: by mail-oa0-f46.google.com with SMTP id m1so8560113oag.5
for <bitcoin-development@lists.sourceforge.net>;
Mon, 28 Jul 2014 05:46:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.52.5 with SMTP id p5mr48807197oeo.55.1406551598498; Mon,
28 Jul 2014 05:46:38 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Mon, 28 Jul 2014 05:46:38 -0700 (PDT)
In-Reply-To: <C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
References: <B097D5C5-8E9E-461D-8FF3-58A661AFB3CB@coinqy.com>
<CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
<C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
Date: Mon, 28 Jul 2014 14:46:38 +0200
X-Google-Sender-Auth: vkD448fQ2aurJpFy0IvDLzMqhmE
Message-ID: <CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mark van Cuijk <mark@coinqy.com>
Content-Type: multipart/alternative; boundary=001a11332c8e630ca304ff405001
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XBkKC-0008IQ-0U
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 12:46:45 -0000
--001a11332c8e630ca304ff405001
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <mark@coinqy.com> wrote:
> Good to see that it has been discussed, but I see the idea has been
> postponed.
>
I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work to
upgrade this and at the moment they're all busy with other things.
> I do like the idea coined by Mike that a PP can issue non-SSL certificate=
s
> for the purpose of merchant identification, as long as a customer is free
> to determine whether he trusts the PP for this purpose.
>
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.
> Regarding the choice of how to authenticate the PP, I=E2=80=99m a bit
> undetermined. Disregarding backward compatibility, I think the extended
> certificate system proposed by Mike is cleaner. However, I don=E2=80=99t =
like the
> concept of requiring two separate signatures for old and new clients.
> Taking backward compatibility in mind, I tend to prefer my proposal.
>
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.
--001a11332c8e630ca304ff405001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <span dir=3D"ltr"><<a href=
=3D"mailto:mark@coinqy.com" target=3D"_blank">mark@coinqy.com</a>></span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Goo=
d to see that it has been discussed, but I see the idea has been postponed.=
</div>
</div></blockquote><div><br></div><div>I'm not sure postponed is the ri=
ght word. It wasn't in v1, but many useful things weren't. It's=
more like, a bunch of people have to do work to upgrade this and at the mo=
ment they're all busy with other things.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><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 cust=
omer is free to determine whether he trusts the PP for this purpose.<br>
</div></div></blockquote><div><br></div><div>I don't think I proposed t=
his exactly? It's the other way around - a merchant issues an extension=
cert to allow the PP to act on their behalf.</div><div>=C2=A0</div><blockq=
uote 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=E2=80=99m a bit undetermined. Disregarding b=
ackward compatibility, I think the extended certificate system proposed by =
Mike is cleaner. However, I don=E2=80=99t 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 o=
f authority requires a signature, but old clients won't understand it.<=
/div>
</div></div></div>
--001a11332c8e630ca304ff405001--
|
