From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; Sun, 27 Jul 2014 08:55:38 +0200 (CEST) From: Mark van Cuijk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=