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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@coinqy.com>) id 1XBIN0-0000Zu-At
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Jul 2014 06:55:46 +0000
Received: from prei.vps.van-cuijk.nl ([79.170.90.37])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1XBIMz-00057o-70
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Jul 2014 06:55:46 +0000
Received: from [192.168.1.10] (ip161-117-174-82.adsl2.static.versatel.nl
[82.174.117.161]) (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 A436341ACC
for <bitcoin-development@lists.sourceforge.net>;
Sun, 27 Jul 2014 08:55:38 +0200 (CEST)
From: Mark van Cuijk <mark@coinqy.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <B097D5C5-8E9E-461D-8FF3-58A661AFB3CB@coinqy.com>
Date: Sun, 27 Jul 2014 08:55:38 +0200
To: bitcoin-development@lists.sourceforge.net
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1XBIMz-00057o-70
Subject: [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: Sun, 27 Jul 2014 06:55:46 -0000
When I asked a non-tech friend to do a BIP 70 payment using our wallet =
as a first round of user experience testing, he made the remark the he =
wanted to do a payment to a merchant, but instead our software shows a =
payment to =93BitPay, Inc.=94
This can be problematic for a couple of reasons:
- As a user you don=92t need to know and trust individual payment =
processors. As long as you can identify and authenticate the merchant, =
you should be able to rely on the merchant=92s choice for a payment =
processor.
- An attacker can become a client of a payment processor, use it to =
create a PaymentRequest message and send this message to a victim as =
part of a MITM attack; the victim now thinks he is paying a merchant =
through the payment processor, but is actually paying the attacker =
through the payment processor.
I have a proposal that can be transformed into a BIP or into an =
extension of BIP 70 and adds a way to include merchant identity in the =
PaymentRequest message and I=92d like to see a discussion on this topic.
At this moment, the PaymentRequest message contains a pki_data field =
with a certificate chain to authenticate the entity that generates the =
message, which in the above case is the payment processor.
I=92m proposing to extends the PaymentRequest message with three more =
fields:
- payee_pki_type
- payee_pki_data
- payee_mandate
The payee_pki_type and payee_pki_data fields can be of the same format =
as the pki_type and pki_data fields, except that they authenticate the =
identity of the merchant, instead of the identity of the payment =
processor. The payee_mandate fields contains a claim by the merchant, =
signed using his own private key, that he grants the payment processor =
the right to collect the payment on his behalf.
The solution is backwards compatible, since existing wallets can ignore =
these fields. They will not show the identity of the merchant, but keep =
showing the identity of the payment processor, they are still able to =
verify the signature in the PaymentRequest message and therefore can =
complete the payment process.
A wallet that understands this extension, needs to check the validity of =
both certificate chains when present and also the validity of the =
mandate. If all is fine, it can now show the identity information from =
the merchant certificate instead of (or besides) the identity of the =
payment processor and allow an end user to correctly identify the =
merchant.
A payment processor supporting this extension may offer it as an =
optional service to clients. A client that wishes to use this extension =
needs to obtain his own certificate from a CA and use it to sign a =
mandate. One potential obstacle is that this process probably needs to =
be repeated both when the certificate of the merchant or the certificate =
of the payment processor expires, but we may be able to address that =
when defining the format of the mandate.
/Mark=
|
