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 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 In-Reply-To: Date: Mon, 28 Jul 2014 15:06:26 +0200 Message-Id: <5E988ED7-845D-4982-9240-155AACD20F66@coinqy.com> References: To: Mike Hearn 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 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 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 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 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.

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%40lis= ts.sourceforge.net/msg04076.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.

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--