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 ) 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 In-Reply-To: Date: Mon, 28 Jul 2014 11:01:06 +0200 Message-Id: References: To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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,

This is very similar to a = proposal I made some time ago:


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.



= --Apple-Mail=_D08E4638-E5B2-48DF-8A12-E0560CC86CC8--