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 <mark@coinqy.com>
In-Reply-To: <CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
Date: Mon, 28 Jul 2014 15:06:26 +0200
Message-Id: <5E988ED7-845D-4982-9240-155AACD20F66@coinqy.com>
References: <B097D5C5-8E9E-461D-8FF3-58A661AFB3CB@coinqy.com>
	<CANEZrP0u-yoS4Sx2sC9uCf0xnzm-g1gYP8atUQO9-s3PW2kYKw@mail.gmail.com>
	<C9BF4A1A-5363-4725-8CFC-9EFE0C0B6B15@coinqy.com>
	<CANEZrP3pU__65h3VFEshtHuXE-aXWkRR47QPXXMNmBrBNcb=SQ@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
Precedence: list


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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On 28 =
Jul 2014, at 14:46 , Mike Hearn &lt;<a =
href=3D"mailto:mike@plan99.net">mike@plan99.net</a>&gt; =
wrote:<br><div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto;"><div style=3D"word-wrap:break-word">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.<br>
</div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div>I referred to =
your idea in&nbsp;<a =
href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourceforge=
.net/msg04076.html">https://www.mail-archive.com/bitcoin-development%40lis=
ts.sourceforge.net/msg04076.html</a>&nbsp;which is indeed not the =
proposal itself.</div><div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote 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=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.<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 =
of authority requires a signature, but old clients won't understand =
it.</div>
</div></div></div>
</blockquote><br></div><div>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.</div><div><br></div><div>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.</div><br><div>/Mark</div></body></html>=

--Apple-Mail=_03BEA670-DFAC-4369-B429-9C9AEE5C768E--